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:

Home	PR Database Search