Re: Bug#489046: findutils: find -execdir + doesn't work anymore

[Adam Borowski]

On Tue, Mar 31, 2009 at 07:31:50AM +0200, Uwe Kleine-König wrote:
> On Thu, Jul 03, 2008 at 09:01:21AM +0100, James Youngman wrote:
> > What scripts are broken by this restriction that didn't already have a
> > bug?

When I run mp3gain -a for starters.

> > I'm very surprised by this.   The + forms of -exec* do not guarantee
> > to use any particular number of command-line arguments per exec, and
> > AFAIK haven't ever guaranteed that.

> When I read the manpage of find, I expected that -execdir + builds a
> maximal list of matching files (limited only by command line length):
> 
>       This variant of the -exec action runs the specified command on
>       the selected files, but the command line is built by appending
>       each selected file name at the end; the total number of
>       invocations of the command will be much less than the number of
>       matched files.  The command line is built in much the same way
>       that xargs builds its command lines. [...]

"much less" "the same way that xargs"

The man page doesn't guarantee that + will use the max possible number of
arguments, but it certainly disagrees with the current behaviour.

> The wording of the info files is slightly better, but IMHO pointing out
> explicitly that no particular length can be expected would be nice.

The description of -s does specify particular lengths.  Yes, it does say "at
most", but the common sense reading suggests find will try to approach that
limit.


Instead of tweaking the docs -- or perhaps in addition to -- let's think how
to fix the behaviour.  What about doing a dup() on the directory, and
comparing the paths once the next match is found?  That would have a side
effect of delaying execution if there's no match for a long time, but I
think that's still much better than doing just one file.


Rawr?!
-- 
1KB             // Microsoft corollary to Hanlon's razor:
                //      Never attribute to stupidity what can be
                //      adequately explained by malice.