参数展开的行为特性：为何ls $foo与ls `执行行为不同？

这个问题问得很有意思，刚好戳中了Shell命令解析流程里的一个关键细节！咱们一步一步拆解来看：

首先先明确前提：你设置了foo=''——因为单引号在Shell里是「原样保留内容」的标记，所以foo的实际值就是**一个单独的反引号字符**（）。

接下来对比两种执行场景的差异：

场景1：直接执行ls #

当你直接在终端敲这个命令时，Shell会按标准的解析顺序处理：

• 它首先扫描命令行文本，立刻识别到反引号是「命令替换」的起始标记——Shell会认为你要把反引号包裹的命令执行结果替换到当前位置。
• 但这里只有一个起始反引号，没有对应的闭合反引号，也没有要执行的命令内容，所以Shell会进入续行等待状态（通常显示>提示符），等着你补全命令替换的内容，或者你按Ctrl+C中断。

场景2：执行ls $foo #

这时候Shell的处理逻辑完全不同：

• 第一步，Shell先处理变量展开：把$foo替换成它的实际值，也就是那个单独的反引号。这时候命令行看起来和场景1的ls 一模一样，但本质上已经不一样了！
• 核心关键点：Shell的展开流程是一次性扫描处理的。变量展开完成后，Shell不会再回头重新扫描展开后的内容，去识别里面的特殊符号（比如反引号）。也就是说，这个反引号已经被当作一个普通的字符串参数，而不是命令替换的标记了。
• 最终，ls命令收到的参数就是一个反引号字符，它会尝试在当前目录下查找名为```的文件：如果这个文件存在，就正常列出；如果不存在，就报「没有那个文件或目录」的错误，绝对不会进入命令替换的等待状态。

你可以做个小验证：先执行touch \``创建一个名为反引号的文件，再跑ls $foo，就能看到这个文件被列出来；而直接敲ls `，还是会进入等待输入的状态。

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