Re: find -lname and -ilname implemented

From: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@xxxxxxxxx>
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@xxxxxxxxxx> wrote:

In message: <20080223123556.3eee709d@xxxxxxxxxxxxxxx>
Mike Meyer <mwm@xxxxxxxxx> writes:
: On Sat, 23 Feb 2008 00:03:08 -0700 (MST) "M. Warner Losh" <imp@xxxxxxxxxx> wrote:
:
: > Sorry to be lame and follow up to my original email, but Ruslan was
: > way too quick to give me feedback :-)
: >
: > I also did a few more of the really easy ones, and added a list of
: > ones that we haven't implemented yet.
: >
: > Comments?
:
: 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. 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.

It is yet another barrier to entry for people converting from Linux to
FreeBSD. 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.

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.

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.

Warner

_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: find -lname and -ilname implemented
    ... gratuitous changes to make things compatible with GNU. ... That they add no new functionality, but only exist to make things ... That would help people outside the BSD community as well. ... I think you may underestimate the value of compatibility. ...
    (freebsd-hackers)
  • Re: find -lname and -ilname implemented
    ... gratuitous changes to make things compatible with GNU. ... That they add no new functionality, but only exist to make things ... just as well call 'POSIX' compatibility gratuitous. ... the GNU utilities represent a de-facto standard that we must conform ...
    (freebsd-hackers)
  • Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
    ... They basically have regex tests, but nothing locale specific, since locale ordering is different from platform to platform. ... GNU grep has some regression test, which doesn't pass completely itself either. ... Later, when Andrey pointed it out, I realized that my workarounds adressed those incompatibilities but didn't work completely, they broke compatibility at other places, thus I just removed them, because it was not that easy to fix. ...
    (freebsd-hackers)
  • Re: CFT: BSD-licensed grep [Fwd: cvs commit: ports/textproc/bsdgrep Makefile distinfo]
    ... They basically have regex tests, but nothing locale specific, since locale ordering is different from platform to platform. ... GNU grep has some regression test, which doesn't pass completely itself either. ... Later, when Andrey pointed it out, I realized that my workarounds adressed those incompatibilities but didn't work completely, they broke compatibility at other places, thus I just removed them, because it was not that easy to fix. ...
    (freebsd-current)
  • find -lname and -ilname implemented
    ... gratuitous changes to make things compatible with GNU. ... That they add no new functionality, but only exist to make things ... just as well call 'POSIX' compatibility gratuitous. ... As far as I can see (and I used Linux ...
    (freebsd-hackers)