From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 21:22:40 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E30AF16A410 for ; Sat, 23 Feb 2008 21:22:40 +0000 (UTC) (envelope-from jonathan+freebsd-hackers@hst.org.za) Received: from hermes.hst.org.za (onix.hst.org.za [209.203.2.133]) by mx1.freebsd.org (Postfix) with ESMTP id AFA6613C538 for ; Sat, 23 Feb 2008 21:22:38 +0000 (UTC) (envelope-from jonathan+freebsd-hackers@hst.org.za) Received: from [10.1.11.1] ([10.1.11.1]) (authenticated bits=0) by hermes.hst.org.za (8.13.8/8.13.8) with ESMTP id m1NLEMn3058803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 23 Feb 2008 23:14:23 +0200 (SAST) (envelope-from jonathan+freebsd-hackers@hst.org.za) From: Jonathan McKeown To: freebsd-hackers@freebsd.org Date: Sat, 23 Feb 2008 23:22:45 +0200 User-Agent: KMail/1.9.4 X-Face: $@VrUx^RHy/}yu]jKf/<4T%/d|F+$j-Ol2"2J$q+%OK1]&/G_S9(=?utf-8?q?HkaQ*=60!=3FYOK=3FY!=27M=60C=0A=09aP=5C9nVPF8Q=7DCilHH8l=3B=7E!4?= =?utf-8?q?2HK6=273lg4J=7Daz?=@1Dqqh:J]M^"YPn*2IWrZON$1+G?oX3@ =?utf-8?q?k=230=0A=0954XDRg=3DYn=5FF-etwot4U=24b?=dTS{i X-Spam-Score: -4.399 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.61 on 209.203.2.133 Subject: find -lname and -ilname implemented X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2008 21:22:41 -0000 [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 > 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" wrote: > > > In message: <20080223123556.3eee709d at bhuda.mired.org> > > > > > > Mike Meyer 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