Expect中send命令双短横线(--)的作用及代码差异解析

先看你给出的代码示例：

#!/usr/bin/env expect
spawn -noecho git_script.sh
expect "Are you sure you want to continue connecting (yes/no/[fingerprint])? "

send "yes\r" 
# below with dashes
send -- "yes\r" 

直接结论：当前示例中两者效果完全相同 #

因为你发送的字符串是yes\r，开头没有-，所以send命令会直接把它当作普通字符串处理，带不带--没有区别。

--的真正作用：避免字符串被误判为命令选项 #

--是Expect的通用"选项终止标记"，核心作用是明确告诉命令：后面的内容全部是普通字符串，不要尝试解析成命令的选项参数。

为什么需要这个？原因有两个：

• Expect的命令（包括send）可能在未来版本新增以-开头的选项。如果你的代码里要发送的字符串恰好以-开头（比如-confirm\r），直接写send "-confirm\r"的话，Expect会误以为-confirm是一个新的命令选项，导致报错或者执行异常。
• 如果你发送的是动态生成的字符串（比如从变量读取的内容），无法提前确定它会不会以-开头，加上--能彻底避免误判问题。

举个实际的例子：
如果要发送字符串-yes\r，直接写：

send "-yes\r"

Expect会尝试解析-yes为命令选项，这显然不是你想要的结果；但如果写成：

send -- "-yes\r"

Expect就会把-yes\r完整当作普通字符串发送，不会做任何选项解析。

对应手册说明的通俗解释 #

手册里的这段说明：

--标志会强制将下一个参数解释为字符串而非选项。无论字符串是否看起来像选项，都可以在其前面加上"--"。这提供了一种可靠的机制来指定可变字符串，避免因某些字符串意外看起来像选项而出错。（所有以"-"开头的字符串都保留为未来的选项。）

翻译成人话就是：

1. 只要加了--，后面的内容就100%是字符串，不会被当成命令选项。
2. 不管你要发的字符串像不像选项，加--都没坏处，反而能避免未来兼容问题。
3. 所有以-开头的字符串，Expect都留着给未来加新选项用，所以别随便用-开头的字符串直接当参数。

内容的提问来源于stack exchange，提问作者cloudscape-germany