[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Adam Borowski
Subject: Re: Bug#489046: findutils: find -execdir + doesn't work anymore
Date: Tue, 31 Mar 2009 09:40:55 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

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

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]