Question

我记得在ksh中使用一个旧的中档，并动态构建了我缓冲区中可用的2kb以上的命令。

我最近遇到一个问题，其中一个可能的简单修复方法可能是创建带有许多长参数的长命令。一位同事问现代bash的局限性是什么，我想到我一无所知。搜索所有内容似乎都被历史记录缓冲区中的行数所困扰，但这与此处无关。

所以我进行了一些测试（请在这里检查我的逻辑...）

time echo $( printf "%01024d" $( seq 1 $max ) ) | wc -c

我进行了一些简单的测试，并取得了巨大的成功。即使在笔记本电脑的git bash仿真环境中，如果我使用max=32运行它，也会得到

$: time echo $( printf "%01024d" $( seq 1 $max ) ) | wc -c
32769

real    0m0.251s
user    0m0.061s
sys     0m0.215s

这是一个echo，后跟32个1kb字符串作为空格分隔的参数，通过管道传送到wc -c，报告了适当的字节数，大约需要四分之一秒。不用说我感到高兴和惊讶，所以我开始将max加倍以寻找上限...并失败了。看看这个。

max=40960
$: time echo $( printf "%01024d" $( seq 0 40960 ) ) | wc -c
41944065

real    0m10.985s
user    0m4.117s
sys     0m7.565s

需要11秒钟来处理，但这是一条41MB的命令行，可以成功创建，加载，执行和解析。

该死的...这个规格的上限是什么？

和/或由于某种原因，该测试不能很好地证明我可以构建几乎任意长的命令？

Answer 1

主要问题的简短答案是：

命令行长度的限制不是由Shell施加的，而是由操作系统施加的。该限制通常在数百KB的范围内。