Paul,
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.
The one change I won't include is the switch from -exec to -xargs.
Although I think -xargs is better, I think it's more important to
stick to the existing behaviour. This stands a much better chance
of being accepted than an invention of a new primary. Also, if
the question of whether "-exec ... +" is allowed as an extension
is not settled by standardizing it, I am certain that it would end
up as an explicitly-allowed extension in the new revision anyway.
I can't see the vendors of SVR4-derived systems agreeing to remove
this feature from their find commands.
Geoff.
Paul Eggert <yyyyyy@xxxxxxxxxxx> wrote, on Mon 26 Mar 2001:
>
> I see some problems with that draft spec, and I have a proposed
> solution that I hope clears them all up. Here are the problems:
>
> 1. SVR4 does not implement the proposed behavior in some cases.
>
> Here is a contrived example:
>
> find / -prune -exec echo {} {} +
>
> The proposal requires that the output be either a single "/ /"
> line or two "/" lines, but under SVR4 (Solaris 8), the output is
> empty.
>
> 2. The proposal is incompatible with the current POSIX standard.
>
> Here is a contrived example:
>
> find / -prune -exec echo {} + -exec echo FOO ';'
>
> Under the current POSIX standard, this command must output "/ +
> -exec echo FOO". But the proposal would require it to output
> "FOO" and then "/" instead. This example is unlikely in practice,
> but other, more complicated examples are more likely.
>
> 3. The proposal does not specify the order of aggregated operands.
> For example, the output of the command
>
> find / /usr -prune -exec echo {} +
>
> might be
>
> /usr /
>
> I don't think this implementation freedom is useful; it's more
> useful to require the aggregation to be in-order. Consider, for
> example, "find . -depth -exec chmod a-rwx {} +".
>
> 4. The proposal does not cover the issue of the order of evaluation
> of primaries in the presence of "-exec ... +". For example, the
> output of the command
>
> find / /usr -prune -exec echo {} + -exec echo {} ';'
>
> might be
>
> /
> /usr
> / /usr
>
> or it might be
>
> /
> / /usr
> /usr
>
> but this is not clear from the proposal.
>
> 5. The proposal requires that ARG_MAX not be exceeded, but this is
> impossible if a single file name exceeds this limit.
>
> 6. The proposal provides no way for invoker of "find" to discover
> whether the "-exec ... +" commands failed.
>
>
> Here is a proposed solution to the above problems.
>
> Add the following option to "find".
>
> -xargs utility_name [argument . . .] ;
>
> The primary shall evaluate as true. The end of the prmary
> expression shall be punctuated by a semicolon. Path names for
> which the primary is evaluated shall be aggregated into lists, and
> the utility utility_name shall be invoked once for each list of
> aggregated path names. Each invocation shall begin after the last
> path name in the list is aggregated, and shall exit before 'find'
> exits and before the first path name in the next list (if any) is
> aggregated for this primary, but it is otherwise unspecified
> whether the invocation occurs before, during, or after the
> evaluations of other primaries. If any invocation returns a
> non-zero value as exit status, find shall return a non-zero exit
> status. An argument containing only the two characters "{}" shall
> be replaced by the nonempty list of path names, with each path
> name passed as a separate argument to the invoked utility in the
> same order that it was aggregated. The size of each non-singleton
> list of path names shall be limited such that execution of the
> utility does not cause the system's {ARG_MAX} limit to be
> exceeded. The current directory for the invocation of
> utility_name shall be the same as the current directory when the
> find utility was started. If the utility_name names any of the
> special built-in utilities in Section 2.14, the results are
> undefined.
>
>
> Arguments for this solution:
>
> * Using "-xargs command ;" rather than "-exec command +" avoids the
> POSIX incompatibilities.
>
> * This solution differs from XVR4, but the behavior that you proposed
> differs as well (albeit in a smaller way).
>
> * This solution specifies order of evaluation (without overspecifying
> it, I hope).
>
> * This solution addresses the ARG_MAX issue.
>
> * This solution allows the invoker of "find" to discover errors in the
> invoked utility.
--
Geoff Clare yyy@xxxxxxxxxxx
UniSoft Limited, London, England. yyy@xxxxxxxxxx
|