> Paul Eggert <yyyyyy@xxxxxxxxxxx> wrote, on Tue 27 Mar 2001:
> >
> > > Although I think -xargs is better, I think it's more important to
> > > stick to the existing behaviour.
> >
> > I'm not so sure of that. The existing behavior is not documented in
> > the most popular SVR4 implementation (namely Solaris), and the
> > behavior doesn't always follow the documentation available in other
> > SVR4 implementations. For example:
> >
> > find / -prune '(' -exec echo {} + ')'
> >
> > doesn't work as documented: it reports an error instead.
>
> I assume that's just a bug. I imagine David Korn intended that
> it should work properly if used like that. (David?)
I didn't go back to my archives and look the the original code,
but I run this here and got
$ find / -prune '(' -exec echo {} + ')'
/
without any reports of an error. However, our find is now built
with the fts() interface, not ftw() although I don't see
why this would make any difference. In any event, an implementation
which considers this an error has a bug.
>
> > > Also, if the question of whether "-exec ... +" is allowed as an
> > > extension
> >
> > I don't see how it can possibly be allowed as an extension under the
> > current standard.
>
> We've been over that issue before. The feature predates POSIX.2 by
> several years. I doubt very much if the intention was for POSIX.2 to
> forbid the feature.
>
> > The only way that I can see it as a pure extension, is to say that the
> > new behavior applies only if the last two arguments are "{}" "+", or
> > if no argument after the "+" is ";", or some weird restriction like
> > that.
>
> The text I proposed says that "+" is only treated as a terminator if
> it follows "{}". I think with this restriction the chances of a
> "normal" use of "+" being taken as a terminator are very small.
> I certainly wouldn't support the unrestricted treatment of "+" as a
> terminator, since that would be quite likely to cause problems with
> uses such as:
>
> find . -type f -exec grep + {} \;
>
> to search for "+" characters in files.
>
> > > I can't see the vendors of SVR4-derived systems agreeing to remove
> > > this feature from their find commands.
> >
> > I can. They have to, to conform to the current standard.
>
> In cases where there is a genuine mistake in the standard, vendors
> don't break their systems in order to comply. They ask for a PASC
> interpretation (which will say "the standard says what it says, but
> concerns have been raised with the sponsor") so that the problem
> with the standard will be fixed in the next revision. In the meantime
> they can say the behaviour of their system is allowed because there
> is a mistake in the standard that has been officially acknowledged.
>
> Whether or not the "find -exec ... +" issue is a genuine mistake
> remains to be seen, but it seems very likely to me. If it was
> intentional it would have been mentioned in the rationale.
>
> > > You have raised some valid points, and I agree with most of them.
> > > I will incorporate the appropriate parts of your changes into my
> > > suggested solution and send it to the POSIX.2 interps reflector.
> >
> > What reflector is that? Sorry, I'm not plugged into it. I'd like to
> > see your revised solution, whenever it's available. (Perhaps I can
> > talk you into -xargs eventually. :-)
>
> I'll send you the new text off-list, as I don't want to stimulate further
> discussion of the details here. If anyone wants to discuss the text,
> they can subscribe to the POSIX.2 interps reflector at the URL that
> Andrew Josey just gave out.
>
>
> --
> Geoff Clare yyy@xxxxxxxxxxx
> UniSoft Limited, London, England. yyy@xxxxxxxxxx
>
>
David Korn
research!dgk
yyy@xxxxxxxxxxxxxxxx
|