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