[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
bin/46158: find(1) lies
>Synopsis: find(1) lies
>Arrival-Date: Fri Mar 09 12:35:00 +0000 2012
>Originator: Robert Elz
>Release: NetBSD 2 -> current (everything for the past 9.5 years)
Prince of Songkla University
System: NetBSD jade.coe.psu.ac.th 5.1_STABLE NetBSD 5.1_STABLE
(JADE-1.12-20120130) #27: Tue Jan 31 05:20:31 ICT 2012
This is non-critical/low because this problem has been around
for almost 10 years now, and doesn't seem to bother anyone
too much. Yet:
find(1) claims ...
All primaries which take a numeric argument of n allow the number to be
preceded by a plus sign (``+'') or a minus sign (``-''). A preceding
plus sign means ``more than n'', a preceding minus sign means ``less than
n'', and neither means ``exactly n''.
Note in particular the "All".
Then consider the 2 primaries ...
True if the current search depth is less than or equal to what is
specified in n.
True if the current search depth is at least what is specified in
In neither of those is the numeric argument treated the way
that the man page promised will be used for "All primaries that
take a numeric argument" yet they take a numeric argument, and
even use find(1)'s 'n' arg notation to indicate that.
I know those two were added (in Sept 2002 - which is why the 9.5
years of lies) the way they were to be compatible with other versions
of find - pity that - we really should not allow other people's
mistakes to cause us to make similar mistakes. The right way to
allow the functionality would have been to add a single primitive
(-depth would have been nice had it not already been used elsewhere)
that tests the numeric parameter the same way all other numeric
parameters are tested.
While I am here, I also see that -user, which doesn't strictly
take a numeric argument, but which does allow a numeric value instead
of the "uname" does (correctly, more or less) allow the +n n & -n
forms (and is documented to do so), but -group does not, yet its arg
is documented as being able to be numeric (the doc doesn't have the
extra comment that the -user section includes about what that means
RTFM, UTSL ...
For the "more or less" comment in the last paragraph of the
Description section of this PR, consider
find / -user 0c
find / -user +0c
Both fail (assuming your system doesn't have users with either of
those user names of course), but they fail in different ways, caused
by the somewhat bizarre way the arg is tested to see if it is
numeric. Parsing the args to find is not where find spends its
time .. we could afford a few extra nanoseconds to do it properly.
Fixing the doc would be as simple as s/All/Most/ - but that would be
a disgusting fix, and lead to a man page that means almost nothing.
Better would be to discard the -mxxdepth primitives and replace them
with something rational. If not completely discarded (because of
compat reasons) they could at least be augmented by a sane primitive
and relegated to being documented as a a couple of very weird non
standard special cases.
-group should get processing added similar to what was done for -user.
Perhaps both of those could benefit from using a function like:
c = *str;
if (c == '+' || c == '-')
for (p = str; c = *p++; )
return (p > str);
rather than screwing around with testing whether atoi() returns 0
(and then trying to handle the special cases) to determine if the
arg really is numeric or not (for all I know there might already be
a libc function that does this) to avoid getting errors from
find_parsenum() so we can have a consistent "no such user" (or
group) error message for all bogus args to -user (and -group).
Main Index |
Thread Index |