This script: > echo aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa | \ > xargs -I '{}' echo "'{}' xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx '{}'" fails: > xargs: command line cannot be assembled, too long The resulting command line has only 3 arguments: 80, 100, and 80 characters. This is quite a short command line, but xargs(1) fails for some reason. xargs(1) should be able to assemble commands as long as they can be executed, which is much longer than the above example. FreeBSD 13.2
Created attachment 244183 [details] testcase.sh
The command being assembled has _one_ arg, not three, and that arg is 266 characters long. "The resulting arguments, after replacement is done, will not be allowed to grow beyond replsize (or 255 if no -S flag is specified) bytes..." 266 is greater than 255 so it fails.
Yes, it has one argument. I think it would be a good improvement to get rid of the -S limit. Currently xargs's manpage says: > -S replsize > Specify the amount of space (in bytes) that -I can use for > replacements. The default for replsize is 255. It isn't clear why should this limit even be applied. The limitation should be the same as the limitation that the system imposes on the command line length that can be run. It isn't beneficial for xargs(1) to have another, lower limit in case when replacements are done. I found this problem when xargs failed during tests of devel/util-linux. xargs is used there and the tests run fine on Linux, but they fail on FreeBSD due to this problem.
(In reply to Yuri Victorovich from comment #3) I concur that the limit is silly and should be removed. What the spec currently requires is that _if_ there is a limit, it must be at least 255 bytes. However, a former version of the spec specified the 255 character limit: v5 (1997) and v6 (2004): "Constructed arguments cannot grow larger than 255 bytes." v7 (2008): "Each of these constructed arguments cannot grow larger than an implementation-defined limit greater than or equal to 255 bytes."
^Triage: changing Product.
^Triage: shorten summary.
I can't reproduce this. When I execute the testcase, this is what I get: ~/test$ sh run.sh 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx '{}' The second replstr is not replaced. If I shorten the match string, then both are replaced. ~/test$ sh run.sh 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
(In reply to Fernando Apesteguía from comment #7) see commit f058359ba5 for the change in behavior
(In reply to Andrew "RhodiumToad" Gierth from comment #8) I see. So the problem is not that there wasn't a limit before f058359ba5 and after f058359ba5 there is one. The problem f058359ba5 fixed was that the output of xargs was broken for very long substitution strings and after f058359ba5 an error is reported.