NetBSD Problem Report #46158
From kre@munnari.OZ.AU Fri Mar 9 12:30:58 2012
Return-Path: <kre@munnari.OZ.AU>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
by www.NetBSD.org (Postfix) with ESMTP id 0E41C63B8C0
for <gnats-bugs@gnats.NetBSD.org>; Fri, 9 Mar 2012 12:30:58 +0000 (UTC)
Message-Id: <201203091230.q29CUpkG000973@jade.coe.psu.ac.th>
Date: Fri, 9 Mar 2012 19:30:51 +0700 (ICT)
From: kre@munnari.OZ.AU
To: gnats-bugs@gnats.NetBSD.org
Subject: find(1) lies
X-Send-Pr-Version: 3.95
>Number: 46158
>Category: bin
>Synopsis: find(1) lies
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: pgoyette
>State: closed
>Class: doc-bug
>Submitter-Id: net
>Arrival-Date: Fri Mar 09 12:35:00 +0000 2012
>Closed-Date: Sun Jun 12 11:30:34 +0000 2016
>Last-Modified: Sun Jun 12 20:55:00 +0000 2016
>Originator: Robert Elz
>Release: NetBSD 2 -> current (everything for the past 9.5 years)
>Organization:
Prince of Songkla University
>Environment:
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 kre@jade.coe.psu.ac.th:/usr/obj/5/kernels/i386/JADE i386
Architecture: i386
Machine: i386
>Description:
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 ...
-maxdepth n
True if the current search depth is less than or equal to what is
specified in n.
-mindepth n
True if the current search depth is at least what is specified in
n.
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
however).
>How-To-Repeat:
RTFM, UTSL ...
For the "more or less" comment in the last paragraph of the
Description section of this PR, consider
find / -user 0c
compared with
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.
>Fix:
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:
bool
numstring(char *str)
{
char *p;
char c;
c = *str;
if (c == '+' || c == '-')
str++;
for (p = str; c = *p++; )
if (!isdigit(c))
return false;
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).
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: bin-bug-people->pgoyette
Responsible-Changed-By: pgoyette@NetBSD.org
Responsible-Changed-When: Sun, 12 Jun 2016 11:30:34 +0000
Responsible-Changed-Why:
I took care of it.
State-Changed-From-To: open->closed
State-Changed-By: pgoyette@NetBSD.org
State-Changed-When: Sun, 12 Jun 2016 11:30:34 +0000
State-Changed-Why:
In private email from originator, my recent commit "essentially fixes
PR bin/46158 - all the other moaning in that PR should really be somplace
else."
From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/46158 CVS commit: src/usr.bin/find
Date: Sun, 12 Jun 2016 20:50:11 +0000
Module Name: src
Committed By: dholland
Date: Sun Jun 12 20:50:10 UTC 2016
Modified Files:
src/usr.bin/find: find.1 function.c
Log Message:
Extend the numeric handling for uids with -user to gids with -group, and
document it. Leftover bit of PR 46158.
To generate a diff of this commit:
cvs rdiff -u -r1.82 -r1.83 src/usr.bin/find/find.1
cvs rdiff -u -r1.72 -r1.73 src/usr.bin/find/function.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.