如何在SSH的pkill Bash命令中正确转义双引号？

最近碰到了个挺头疼的问题：同样的命令，交互式SSH登录后执行完全正常，但用非交互式方式传递时，单层引号转义就失效了，只有两层转义才能正常工作。先给大家看看我测试的几个场景：

测试1：交互式执行（一切正常） #

$ ssh root@123.123.123.123
123.123.123.123# pkill -f "stalled process name"; commands_to_restart; some_more_commands;
many many lines of output demonstrating success
123.123.123.123# exit;

运行结果：一切正常，命令顺利执行并输出成功信息

测试2：单层引号转义的非交互式命令（完全没反应） #

$ ssh root@123.123.123.123 "pkill -f \"\"\"stalled process name\"\"\"";"\ > "commands_to_restart; some_more_commands;";

运行结果：无任何输出，远程服务器完全没执行指定操作

测试3：两层引号转义的非交互式命令（正常生效） #

$ ssh root@123.123.123.123 "echo \"\"\"pkill -f \"\"\\\"\"stalled process name\"\"\\\"\""; \"\ > "commands_to_restart; some_more_commands;"\"";"; pkill -f "stalled process name"; commands_to_restart; some_more_commands;

运行结果：命令正常执行，和交互式效果一致

问题根源：不是转义的锅，是SSH的命令解析流程！ #

其实一开始我也以为是引号转义的问题，但仔细捋了捋SSH的工作机制才明白：当你用非交互式方式给SSH传命令时，本地的Bash会先对命令里的引号、转义字符做一次解析，然后才把解析后的内容发送给远程服务器执行。

就拿测试2的命令来说，本地Bash处理完那些转义引号后，传到远程服务器的命令可能已经丢失了正确的引号结构——比如pkill -f后面的进程名没被正确包裹，导致匹配不到目标进程，后续的重启命令也没被远程Bash识别成需要执行的内容，自然就没反应了。

而两层转义相当于给本地Bash加了一层“保护”，让它解析后能把正确的带引号的命令原封不动传递到远程，远程Bash才能正确识别并执行所有命令。

更简单的解决方案：用单引号包裹远程命令 #

其实没必要折腾多层转义，直接用单引号把远程要执行的整个命令包起来就行——因为本地Bash不会解析单引号内部的任何字符，这样就能确保远程服务器收到的命令和你想执行的完全一致：

$ ssh root@123.123.123.123 'pkill -f "stalled process name"; commands_to_restart; some_more_commands;'

如果你的进程名里有特殊字符，或者需要在远程命令里用变量，也可以把命令写成一个单独的脚本文件，传到远程后执行，这样不仅清晰，还能避免各种转义坑。

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