>Number:         11251
>Category:       bin
>Synopsis:       find(1) does not support -amin parameter.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Oct 17 21:21:01 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Richard Rauch
>Release:        1.5_ALPHA (early August? mid-August?)
>Organization:
  "I probably don't know what I'm talking about."  --rkr@rkr.kcnet.com
>Environment:
	
System: NetBSD rkr.kcnet.com 1.5_ALPHA NetBSD 1.5_ALPHA (rkrGENERIC) #0: Sun Aug 6 17:44:22 PDT 2000 root@:/usr/src/sys/arch/i386/compile/rkrGENERIC i386


>Description:
	find(1)'s -amin option is not being recognized.  Presumably this
	is obscure, since I believe that this has been broken for some
	time.  Nonetheless, it's a documented feature...(^&

	(I can't remember when I first noticed this; I wasn't sure if it
	was a bug, and wasn't running -current, and I figured that such
	a bug couldn't lurk for long...now I see it's in the 1.5_ALPHA,
	so...)
>How-To-Repeat:
	$ /usr/bin/find . -amin 1
	find: -amin: unknown option
>Fix:
	The problem is that the {options} table (in options.c) is supposed
	to be sorted (``lexically sorted'') for a bsearch() call.  Someone
	has interchanged "-and" and "-amin".  As of the version that I have,
	these are the only two out of order (dated 2000/03/16 18:44:30).

	There are four alternative solutions that occur to me:

	(a) Sort the table during initialization.  This probably isn't
	worth the trouble, but would assure that the table is always
	correct when used.  If you Really Want to use bsearch(), this might
	be the Right Thing To Do.

	(b) Change the bsearch() into a simpler search mechanism.  Probably
	not worth the trouble, but the efficiency concerns should be
	negligible (unless you repeatedly run find on empty directories
	with an obscenely long list of parameters...(^&).

	(c) Convert the code to drop the table contents into a hash table
	during init---more efficient than sorting (probably), and probably
	faster than bsearch() for lookup.  (Though the table is small, so
	the difference won't be large in any direction.)

	(d) Simplest in-place fix: Move the "-and" string AFTER "-amin" in the
	table, so that it is sorted, per the comment.  Also, of course, the
	most fragile against future bugs of like kind.


	The patch for (d) is trivial (^&:

--- option.c    2000/10/18 03:11:14     1.1
+++ option.c    2000/10/18 03:12:39
@@ -65,8 +65,8 @@
	{ "(",          N_OPENPAREN,    c_openparen,    0 },
	{ ")",          N_CLOSEPAREN,   c_closeparen,   0 },
	{ "-a",         N_AND,          c_null,         0 },
-	{ "-and",       N_AND,          c_null,         0 },
	{ "-amin",      N_AMIN,         c_amin,         1 },
+	{ "-and",       N_AND,          c_null,         0 },
	{ "-atime",     N_ATIME,        c_atime,        1 },
	{ "-cmin",      N_CMIN,         c_cmin,         1 },
	{ "-ctime",     N_CTIME,        c_ctime,        1 },

>Release-Note:
>Audit-Trail:
>Unformatted: