On Thu, Dec 04, 2014 at 03:55:08AM -0500, Ted Unangst wrote: > On Thu, Dec 04, 2014 at 07:40, Jason McIntyre wrote: > > On Thu, Dec 04, 2014 at 12:03:01AM +0100, Ingo Schwarze wrote: > >> Hi Ted, > >> > >> Ted Unangst wrote on Wed, Dec 03, 2014 at 05:41:41PM -0500: > >> > >> > Here's a revised diff against current. It just notes that the > >> > extension spellings are such. > >> > >> I'm OK with that, discouraging gratuitiously non-standard syntax > >> makes a lot of sense. > >> > > > > when find(1) was imported into openbsd (or when openbsd itself was > > imported), it came with the syntax "-and" and "-or". that was in > > 1995, some 19 years ago. beyond that, well you'd be much better > > qualified to tell me the history of it. > > > > so how have you gone from that to "gratuitiously non-standard syntax"? > > if it has existed for 19 years (and before that), in this context it is > > completely standard syntax. > > I'll note that the -a and -o syntax was also supported since the > initial import. It merely wasn't documented. All we're doing here is > fixing a bug. >
the bug is fixed. we're now really discussing whether the man page for find(1) should sideline -and and -or in favour of -a and -o. > In this case there is a real standard (as opposed to just > historic practice) describing the utility. > > http://pubs.opengroup.org/onlinepubs/009695399/utilities/find.html > really. > > i'll ask again: are we deprecating this syntax to such an extent that we > > are actively asking people not to use it and, if so, why? > > I think so. I like the following rules. > > 1. Prefer the better alternative. > > 2. When alternatives are equal, prefer the officially standardized > alternative. > right. so our examples use the portable format. > The BSD syntax under discussion here is certainly traditional, but > it's also gratuitous. It's not better. It doesn't let me do > something new and different, like the -print0 extension, that's actually > useful. > > >From the perspective of an implementor, I find it very annoying trying > to deal with all the de facto standards and variations that arise > when people do not write their code and scripts to conform to the > standard. This is like all those shell scripts that start with > #!/bin/bash even though they run under plain sh just fine. I would not > wish to further inflict that on others. > none of that really has any bearing on the man page. it just means you, tedu, would like people to write portable code. for people wishing to use find(1) portably, they should read the notes in STANDARDS and/or the relevant standards, and decide whether to use non-portable extensions or not. for people who don;t care, they can use whatever components of find they want. so i think we should document it normally (i.e. no change required) or we mark it as deprecated. but not say "oh by the way, we support this too". and i honestly don;t see the gain in doing that. jmc
