find -lname and -ilname implemented

[M. Warner Losh]

In message: <20080224171155.GD51827 at dracon.ht-systems.ru>
            Stanislav Sedov <stas at FreeBSD.org> writes:
: Should be, probably, spelled as GNU, it's an abbrev.

Actually, you are right, but for the wrong reason.  GNU is an acronym,
so should be all caps.

: > -/* c_simple covers c_prune, c_openparen, c_closeparen, c_not, c_or */
: > +/* c_simple covers c_prune, c_openparen, c_closeparen, c_not, c_or, c_true, c_false */
: >  
: 
: As the result of modification the line now exceeds 80 characters, which is, obviously, bad.

I have a couple of other places to clean up.

: > Index: option.c
: > ===================================================================
: > RCS file: /cache/ncvs/src/usr.bin/find/option.c,v
: > retrieving revision 1.25
: > diff -u -r1.25 option.c
: > --- option.c	5 Apr 2006 23:06:11 -0000	1.25
: > +++ option.c	23 Feb 2008 06:57:54 -0000
: > @@ -58,6 +58,7 @@
: >  int typecompare(const void *, const void *);
: >  
: >  /* NB: the following table must be sorted lexically. */
: > +/* Options listed with C++ comments are in gnu find, but not our find */
: 
: Please, don't commit C++ comments, that violates style(9). Also, gnu should be
: spelled as GNU.

Understood.  Not that I'm going to change it, but understood.

: >  static OPTION const options[] = {
: >  	{ "!",		c_simple,	f_not,		0 },
: >  	{ "(",		c_simple,	f_openparen,	0 },
: > @@ -74,26 +75,38 @@
: >  	{ "-cmin",	c_Xmin,		f_Xmin,		F_TIME_C },
: >  	{ "-cnewer",	c_newer,	f_newer,	F_TIME_C },
: >  	{ "-ctime",	c_Xtime,	f_Xtime,	F_TIME_C },
: > +	{ "-d",		c_depth,	f_depth,	0 },
: > +// -daystart
: >  	{ "-delete",	c_delete,	f_delete,	0 },
: >  	{ "-depth",	c_depth,	f_depth,	0 },
: 
: Why to add just a shortcut for already existent -depth option?
: It makes the utility much complex, but don't add value at all.

Because it makes it more compatible with existing de-facto standards.
It costs us very little to do so.

: >  	{ "-empty",	c_empty,	f_empty,	0 },
: >  	{ "-exec",	c_exec,		f_exec,		0 },
: >  	{ "-execdir",	c_exec,		f_exec,		F_EXECDIR },
: > -	{ "-false",	c_simple,	f_not,		0 },
: > +	{ "-false",	c_simple,	f_false,	0 },
: 
: This brakes FreeBSD compatiblity in the favor of GNU. What will
: old FreeBSD user think when his scripts will stop working
: after next cvsup? I suppose our target not to make FreeBSD
: to look like Linux. If you want to add GNU-like false option,
: please, add it under the different name.

I considered it, but rejected it.  The current -false option doesn't
make any sense at all, likely isn't used, is just a short-cut for '!'
and had a very dubious justification when it was committed.

: No space between "-iwholename" and c_name.
: 
: Also, just a shortcut to -ipath. Also, -iname is much shorter.

Again, for compatibility with existing scripts.  I didn't pick the
names here.

: >  	{ "-links",	c_links,	f_links,	0 },
: > +	{ "-lname",	c_name,		f_name,		F_LINK },
: >  	{ "-ls",	c_ls,		f_ls,		0 },
: >  	{ "-maxdepth",	c_mXXdepth,	f_always_true,	F_MAXDEPTH },
: >  	{ "-mindepth",	c_mXXdepth,	f_always_true,	0 },
: >  	{ "-mmin",	c_Xmin,		f_Xmin,		0 },
: >  	{ "-mnewer",	c_newer,	f_newer,	0 },
: > +	{ "-mount",	c_xdev,		f_always_true,	0 },
: 
: SHortuct to -xdev. Again, much longer one.

Agreed, but for compatibility with existing scripts...

: Warner, I fully understand your intention to make FreeBSD more
: compatible with GNU, but FreeBSD Project historically had much more
: important target - to make a clean designed and not bloated
: system. I'll be happy to see new useful options added to find, but
: in case they isn't just shortcuts to existing ones and don't break
: existing functionality.

There's at least one that adds real, new functionality (-lname and
-ilname).  The minor breakage to FreeBSD users for -false likely will
affect fewer people than the removal of the 'ie' driver.

: If'll take a direction to become a Linux one day - we'll certainly
: loose. There'a lot of examples of this in history - I don't want to
: make the same mistake. It's quite common for BSD and GNU world to
: make different desicions on design of their systems.  That's pretty
: normal. BSD people tend to prefer a clean and simple design, where
: duplication is a bad thing, where GNU people prefer to implement
: every possible functionality in their programs. Linux camp - is
: 'just works' camp, where BSD - 'works perfectly' camp.

It can be a tough judgment call here.  While I generally favor
cleanliness, there's also a lot of gain to be had with being
compatible.

: I understand, that you want to attract more people from the
: GNU/Linux camp to FreeBSD.  But think - people go from Linux to
: FreeBSD for a reason, a reason they want a more clean and simple
: disigned system, perfect system, where good design - is the first,
: and everything another - the last. If we'll take the GNU way - what
: will be the reason for them to go for FreeBSD?

I think you miss my point.  It certainly isn't to attract people from
Linux to FreeBSD.  Rather, it is to remove speed-bumps along the way
if someone has already made that decision.  There's also a fair number
of tools out there that are using the GNU extensions.  If it were one
or two, I'd fix the tools.  However, I keep stubbing my toe on these
issues.

In addition, many of these tools are moving to GPLv3 when they make
relatively minor patches.  This makes them harder to use and deploy.
While one can tolerate GPLv3 software on one's development system, the
deployed systems typically can't tolerate it at all.  By making the
BSD tools more compatible, they can more easily be dropped in to
replace the GNU tools without having to redo one's scripts.

Warner