这个限制远远低于OS(在现代Linux的情况下).
例如：
$/bin/true $(seq 1 100000) $/bin/sh -c "/bin/true $(seq 1 100000)" bash: /bin/sh: Argument list too long
那我该怎么规避这个问题呢？
更新
我想要注意的是,getconf在这里无法帮助(因为这不是系统限制)：
$seq 1 100000 | wc -c 588895 $getconf ARG_MAX 2097152
更新#2
现在我明白了这里的意义.这不是一个shell限制,这是一个系统限制,但是对于每个参数的长度,而不是整个arglist.
$/bin/true $(seq 1 100000) $/bin/true "$(seq 1 100000)" bash: /bin/true: Argument list too long
谢谢CodeGnome的解释.
单个参数必须短于MAX_ARG_STRLEN.
分析
根据this link：
And as additional limit since 2.6.23,one argument must not be longer than MAX_ARG_STRLEN (131072). This might become relevant if you generate a long call like “sh -c ‘generated with long arguments'”.
这正是OP所确定的“问题”.虽然允许的参数数量可能相当大(参见getconf ARG_MAX),当您将引用的命令传递给/ bin / sh时,shell会将引用的命令解释为单个字符串.在OP的示例中,这个单个字符串超出MAX_ARG_STRLEN限制,而不是扩展参数列表的长度.
实施具体
参数限制是具体的实现.然而,this Linux Journal article提出了几种解决方法,包括增加系统限制.这可能不直接适用于OP,但它在一般情况下仍然有用.
做其他事情
OP的问题实际上并不是一个真正的问题.这个问题正在强加一个不能解决现实问题的任意约束.
您可以使用循环轻松解决这个问题.例如,Bash 4：
for i in {1..100000}; do /bin/sh -c "/bin/true $i"; done
工作很好它肯定会很慢,因为您在每次循环中产生一个进程,但它肯定会绕过您遇到的命令行限制.
描述你的真正问题
如果一个循环不能解决您的问题,请更新该问题以描述您实际使用真正长的参数列表解决的问题.探索任意行长限制是一个学术活动,而不是Stack Overflow的主题.
