Sat 17 May 2008 08:53:21 AM UTC, comment #9:
Some anonymous person wrote:
> I can't help but notice that the original bug remains unfixed:
[...]
> $ echo * | xargs -i echo {} foo | wc -l
> xargs: argument line too long
>
> xargs version 4.2.28
... but findutils 4.2.28 was released in 2006. If your point is that a problem remains unfixed, you should be testing with a somewhat newer release, surely.
In any case, the "argument list too long" relates to a kernel limitation, not a bug. The -I (-i) option as specified by POSIX (see for example http://www.opengroup.org/onlinepubs/009695399/utilities/xargs.html) requires the whole input line to be substituted. But the input line itself exceeds the kernel's exec limit.
|
Tue 13 May 2008 09:51:57 PM UTC, comment #8:
I can't help but notice that the original bug remains unfixed:
$ echo * | xargs echo foo | wc -l
5
$ echo * | xargs -i echo {} foo | wc -l
xargs: argument line too long
xargs version 4.2.28
|
Mon 08 Nov 2004 09:35:12 PM UTC, comment #7:
I have made the suggested change to the documentation (this will be included in findutils-4.2.5). The patch is attached.
|
Sun 07 Nov 2004 11:49:20 AM UTC, comment #6:
aarghh, typo.
replace "only split on blanks:" with "only split on newline:"
|
Sun 07 Nov 2004 11:47:07 AM UTC, comment #5:
Jay writes:
> I believe that this is the behaviour of the "-i" option that > shold be expected. Certainly it seems consistent with the
> behaviour of xargs on Solaris.
I think you are right, POSIX/Susv3 (XSI extension) seems to support your interpretation that -i should change xargs from splitting at <space> to only split on blanks:
--------------------------
-I replstr
[XSI] [Option Start] Insert mode: utility is executed for each line from standard input, taking the entire line as a single argument,[...]
--------------------------
And I'd expect -I and -i to be the same.
More supporting data:
a9203835@login__~>uname -a
AIX login 2 5 00404A0A4C00
a9203835@login__~>echo a b | xargs -I'{}' `pwd`/a.out X \{\} Y
Arg 0: [/u/user5/a9203835/a.out]
Arg 1: [X]
Arg 2: [a b]
Arg 3: [Y]
a9203835@login__~>echo a b | xargs `pwd`/a.out X \{\} Y
Arg 0: [/u/user5/a9203835/a.out]
Arg 1: [X]
Arg 2: [{}]
Arg 3: [Y]
Arg 4: [a]
Arg 5: [b]
a9203835@login__~>printf 'a\nb\n' | xargs -I'{}' `pwd`/a.out X \{\} Y
Arg 0: [/u/user5/a9203835/a.out]
Arg 1: [X]
Arg 2: [a]
Arg 3: [Y]
Arg 0: [/u/user5/a9203835/a.out]
Arg 1: [X]
Arg 2: [b]
Arg 3: [Y]
---------------------
AIX's finds provides both -i and -I and both behave identically.
I suggest to update GNU findutil's documentation to clearly note that '-i' stop xargs from splitting at blanks and makes it pass the complete line to the command and /after/ that close this bug.
|
Mon 03 May 2004 10:06:31 AM UTC, comment #4:
I believe that this is the behaviour of the "-i" option that shold be expected. Certainly it seems consistent with the behaviour of xargs on Solaris.
|
Tue 23 Mar 2004 05:20:08 AM UTC, comment #3:
I did some further tests with the following program (C code):
main ( int argc, char **argv ) { int i; for (i = 0; i < argc; i ++) { printf("Arg %d: [%s]\n", i, argv[i]); } }
It shows that -i changes the way xargs invocates its command:
$ echo 0 1 | xargs ./test
Arg 0: [./main]
Arg 1: [0]
Arg 2: [1]
$ echo 0 1 | xargs -i ./test {}
Arg 0: [./main]
Arg 1: [0 1]
strace also confirms this. With -i xargs calls
execve("./main", ["./main", "0 1"], [/* 25 vars */])
whereas normally it calls
execve("./main", ["./main", "0", "1"], [/* 25 vars */]).
Very frustrating. :(
|
Tue 23 Mar 2004 05:11:07 AM UTC, comment #2:
Arg, my "nice workaround" does not really work. It triggers some other bug in xargs' -i.
The following commands ilustrate the bug:
$ touch 0 1 ; echo * | xargs -i rm {}
rm: cannot remove `0 1': No such file or directory
Needless to say, ``xargs rm'' just works. I am just using the -i parameter in this example to show what's broken. I don't see any reason why the above command should fail.
There are some circunstances when the user really needs the -i option (such as to use my workaround for the first bug) and then this second bug bites him.
Is -i really as broken as it seems (and has it been that broken since 1999, when it seems its first bugs were reported) or am I just missing something?
|
Tue 23 Mar 2004 04:27:22 AM UTC, comment #1:
I found out a nice workaround:
$ echo * | xargs | xargs -i echo {} foo | wc -l
9
Still, the bug should be fixed, really fixed.
|
Fri 19 Mar 2004 03:27:25 PM UTC, original submission:
Using -i to xargs makes it stop being useful:
$ echo * | xargs echo foo | wc -l
9
$ echo * | xargs -i echo {} foo | wc -l
xargs: argument line too long
0
I understand that the point of xargs is splitting one long command in multiple commands to avoid errors. If -i is specified, it no longer does that, so using xargs has no advantage over executing the long command directly (and just adds some overhead).
I guess this is the same bug that was reported to Debian's bug tracking system in Jan 1999 (see <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=31858>), though the report there makes it seem like the bug is not as bad as it actually is.
|