带有&符号的远程wget命令的行为不像预期的那样
以下是一些测试结果：
我在本地主机上运行命令，并尝试在远程主机11.160.48.88上执行一些命令。
命令1：
ssh 11.160.48.88 "wget https://raw.githubusercontent.com/mirror/wget/master/README -O wgetReadme"
预期：
文件可以下载并重命名为wgetReadme
结果：
工作按预期进行
命令2：
ssh 11.160.48.88 "wget https://raw.githubusercontent.com/mirror/wget/master/README -O wgetReadme&"
我只需在命令末尾添加&，因为我希望这个命令在后台运行
结果：
文件在远程服务器上为空，我不知道为什么
命令3：
要测试Command 2是否可以在远程服务器上运行，我尝试直接在服务器11.160.48.88上运行该命令。
wget https://raw.githubusercontent.com/mirror/wget/master/README -O wgetReadme&"
结果:有一些wget传输消息打印到stdout，并将该文件下载到wgetReadme。认真地工作。
命令4：
我想知道是否是SIGHUP信号杀死了子进程，我找到了两个证据来证明它不是。
我找到了11.160.48.88，并试图在远程服务器上运行它。
$shopt|grep hup
huponexit off因此，当ssh退出时，子进程将不会接收SIGHUP。
- 我尝试运行另一个命令来证明它是
ssh 11.160.48.88 "wget https://raw.githubusercontent.com/mirror/wget/master/README -O - 2>&1 > wgetReadme&"
结果:该文件可以正确下载到目标文件。
我的问题是为什么Command 2不能像预期的那样工作？
回答 2
Stack Overflow用户
发布于 2020-09-08 07:35:40
因为ssh中的背景作业可能会导致shell在注销时挂起，这是由于两个或多个线程可以访问共享数据时出现的争用条件，并且它们同时尝试更改共享数据，您还可以通过重定向所有三个I/O流(如> /dev/null 2>&1 & )来解决这个问题，因此Nohup命令在您的情况下是有用的，它是一个POSIX命令来忽略HUP (挂起)信号。按照惯例，HUP信号是终端警告依赖的注销进程的方式。因此，我按以下方式更改您的代码：
ssh -f 11.160.48.88 "sh -c 'nohup wget https://raw.githubusercontent.com/mirror/wget/master/README -O - > wgetReadme 2>&1 &'"您可以在https://en.wikipedia.org/wiki/Nohup上阅读更多内容。
Stack Overflow用户
发布于 2020-09-08 07:23:44
&是使进程在后台运行的bash特殊字符。然后，当您远程运行这个命令时，ssh将不再捕获命令的输出。
您应该使用\能够运行您的命令来转义它
在您的示例中：wget https://raw.githubusercontent.com/mirror/wget/master/README -O wgetReadme\&"
问候
https://stackoverflow.com/questions/63788664
复制相似问题
腾讯云开发者
