Linux下SSH命令异常行为咨询：两种cat执行方式的差异原因

第一种情况：ssh -q user@server "cat"卡住的原因 #

当你直接在SSH命令里指定远程执行cat时，远程服务器上启动的cat进程，它的标准输入（stdin）会和SSH会话的输入流绑定——而这个输入流默认就是你本地的终端。

cat命令在不带文件名参数时，本来就会从stdin读取内容，直到收到EOF（文件结束符）才会退出。此时你的本地终端并没有发送EOF，所以远程的cat就一直等着输入，表现为命令卡住，只有你手动按Ctrl+D发送EOF，它才会结束。

第二种情况：ssh -q user@server < filename.txt立即返回的原因 #

这种写法是本地端的输入重定向：你把本地filename.txt的内容（也就是字符串cat）作为整个SSH客户端进程的stdin输入，而不是预先指定远程要执行的命令。

具体流程是：

• SSH客户端启动后，先把filename.txt里的所有内容（这里就是cat这一行）发送给远程服务器的shell
• 远程shell接收到这个字符串后，解析并执行cat命令
• 但此时远程cat进程的stdin已经是EOF状态了——因为本地的文件内容已经全部发送完毕，SSH会话的输入流已经耗尽，所以远程的cat一启动就没东西可读，直接退出，命令也就立即返回了

核心差异总结 #

• 第一种是远程直接执行cat，该命令的stdin绑定到本地终端输入，处于等待输入状态
• 第二种是本地把cat命令字符串传给远程shell执行，远程cat的stdin已无输入，直接结束

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