Email List: Xaustin-group-lX
[All Lists]

Re: find + xargs

To: Paul Eggert <yyyyyy@xxxxxxxxxxx>
Subject: Re: find + xargs
From: yyy@xxxxxxxxxxx (Geoff Clare)
Date: Wed, 28 Mar 2001 09:45:05 +0100
Cc: yyyyyyyyyyyyyy@xxxxxxxxxxxxx
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?)

> > 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

<Prev in Thread] Current Thread [Next in Thread>