C重写Bash：为何echo与grep对空引号参数的接收表现不同

先理清Bash的参数合并规则 #

你在终端执行echo 123''456时，Bash会把相邻的字符串字面量（无论是否带引号）合并成单个参数。这里的123、空引号''、456是三个相邻的字符串字面量，合并后变成单个参数123456，所以echo只收到一个参数，自然输出123456——这和你用execve直接传递三个参数（123、空串、456）是完全不同的场景。

echo确实收到了空串参数，只是输出逻辑掩盖了它 #

当你通过execve传递{"echo", "123", "", "456", NULL}时，echo明确收到了三个参数：123、空串、456。但echo的默认行为是将所有位置参数用单个空格连接后输出，空串参数本身没有字符，所以连接后的结果是123 + 空格 + （空串） + 空格 + 456，最终显示为123 456（部分环境下可能因为echo实现不同显示为单个空格，但核心是空串参数确实被接收了）。你觉得echo没收到空串，只是因为它的输出逻辑让空串的存在感极低。

grep的行为差异源于自身的参数处理逻辑 #

grep ''和grep的行为不同，是因为grep对空串参数有明确的处理规则：空串作为匹配模式时，会匹配所有包含空字符串的行——而任何文本行都包含空字符串（空串是所有字符串的子串），所以grep会输出所有输入行；而不带参数的grep缺少匹配模式，会触发错误提示或进入等待输入的交互状态。这说明grep确实接收到了空串参数，并按照自身逻辑处理。

总结 #

echo和grep都接收到了空串参数，二者的行为差异完全来自程序自身的参数处理逻辑，和execve的传递机制、Shell的解析规则无关。

内容的提问来源于stack exchange，提问作者stefansige