find -lname and -ilname implemented

[Jonathan McKeown]

[Sorry to break threading - I deleted the thread before deciding to respond. I 
can see both sides of this discussion, but I did want to add some hopefully 
thought-provoking comments late on a Saturday night].

[M Warner Losh]
> From: Mike Meyer <mwm-keyword-freebsdhackers2.e313df at mired.org>
> Subject: Re: find -lname and -ilname implemented
> Date: Sat, 23 Feb 2008 13:19:37 -0500
>
> > On Sat, 23 Feb 2008 11:00:47 -0700 (MST) "M. Warner Losh" <imp at 
bsdimp.com> wrote:
> > > In message: <20080223123556.3eee709d at bhuda.mired.org>
> > >
> > >             Mike Meyer <mwm at mired.org> writes:
> > > : How about a question: why are you turning the FreeBSD find into the
> > > : GNU find? The changes in the first patch looked like they added real
> > > : functionality that wasn't available in other tools. These seem to be
> > > : gratuitous changes to make things compatible with GNU.
> > >
> > > The changes aren't gratuitous.  They are well thought out to ensure
> > > maximum compatibility.
> >
> > That they add no new functionality, but only exist to make things
> > compatible with GNU are what make them gratuitous to me.
>
> It adds functionality.
> 
What functionality does

    find path -lname name

add that isn't already available from

    find path -name name -type l

and what other combinations should be special-cased like this?

> That doesn't make it gratuitous.  One might 
> just as well call 'POSIX' compatibility gratuitous.  Like it or not,
> the GNU utilities represent a de-facto standard that we must conform
> to.

So what we're saying is that the Linux community is now as arrogant as 
Microsoft? I don't much like the suggestion that everyone must conform to the 
GNU utilities because GNU/Linux has a dominant position, whether what they do 
makes sense or not, or whether or not it complies with published standards. 
In particular, I think comparing a documented standard from a professional 
body with ``use and custom'' in one particular developer community is 
specious.

At the very least, when patching the manpage, you could point out that this is 
a (potentially non-portable) GNU extension - in the same way that every other 
extension to the POSIX standard is noted.

> > > It is yet another barrier to entry for people converting from Linux to
> > > FreeBSD. 

I keep seeing this argument or variations of it. Yes, different Unix-like OSes 
do things slightly differently. As far as I can see (and I used Linux 
exclusively for as long as I have now been a FreeBSD user, and may well use 
it again in future), the major ``barrier to entry'' is the Linux mindset that 
the Linux way is the only way. In many ways, the sooner a Linux convert is 
forced to face that assumption and overcome it, the better for them.

Of course, if we're in some sort of religious war for converts, perhaps we 
should change the default configuration of ssh to match the Linux distros on 
which remote root access is enabled by default; do away with the wheel group 
and let anyone su to root; install sudo by default instead of having a root 
password; and so on, and so on, and so on...

> > > There's lots of useful scripts that have been written for 
> > > the embedded world that, sadly, assume more functionality in our tools
> > > than are present.  They don't always do nice autoconf things to find
> > > the right tool to use.  The trivial differences between gnu find and
> > > our find serve no real purpose.

So if a script is non-portable because the developer doesn't know any better, 
every OS it might be run on should change itself to match the developer's 
faulty expectations, rather than someone pointing the developer to a resource 
on portable scripting?

> > The problem with this argument is that there are no limits on it,
> > other than the developers definition of "trivial". OS X has already
> > carried this argument to the point that they've replaced /bin/sh with
> > bash.
>
> Don't be rediculous.  I added 1k of extra space to an existing
> utility.  That was part of the calculous in my making the changes I
> did.
>
> Or course, we may need to adopt features from bash into our /bin/sh as
> time marches forward.

Oh goody. Don't get me wrong - I use bash as my user shell; but my scripts 
tend to start off #!/bin/sh. On my system /usr/local/bin/bash is 6 times the 
size of /bin/sh, not to mention the insane list of dependencies. The 
suggestion that we will have to incorporate some of that complexity 
into /bin/sh, again in order to meet the expectations of Linux users who 
don't know, and can't be bothered to find out, that there are shells other 
than bash, and standards other than GNU/Linux, fills me with horror.

> This is no different from what the project has always done.  There's
> nothing new that I've done.  Reviewing all the utilities one will find
> where people have added features or enhanced compatibility with other
> gnu tools.  Don't make me quote all the cvs log entries to prove this
> point (but I will if you don't believe me).
>
> > While I understand that it's easier to fix the BSD find, have you
> > tried filing bug reports with patches for the tools that assume GNU
> > find? That would help people outside the BSD community as well.
>
> Like spitting in the ocean.  There's a bunch of different such tools
> and it is a better investment of my time and everybody else's time to
> make FreeBSD's find work better in these environments rather than
> trying to fix all the places that use it.
>
> I'm also not sure that the maintainers would buy the argument you are
> making here.  People outside the BSD community generally use gnu
> tools.  The percentage of people using other Unicies is small, and
> typically they don't have source to rebuild (Solaris/OpenSolaris is
> one exception I can think of).
>
> In short, I'm continuig the long tradition that we've done as FreeBSD
> and that BSD and other Unix vendors did before us: compatibility with
> other implementations.

Yes, where it makes sense. I'm not at all convinced that this change makes as 
much sense as you obviously think it does - especially given that it doesn't 
add previously unavailable functionality, and that we have a ports system 
which includes a patch stage for dealing with this sort of gratuitous 
non-portability in ported applications.

Jonathan