为什么使用 echo/sudo 时 shell 重定向失败？答案

【问题标题】：Why does shell redirection fail when using echo/sudo?为什么使用 echo/sudo 时 shell 重定向失败？
【发布时间】：2012-07-23 17:18:24
【问题描述】：

我有一个行为异常的简单脚本。

path='/usr/local/bin/new_script'

content='#!/bin/bash\nls'

sudo echo -e "$content" > "$path"

引发错误：

bash: /usr/local/bin/new_script: Permission denied

我做错了什么？

【问题讨论】：

【解决方案1】：

您可以使用以下方式进行重定向：

sudo sh -c "echo -e '$content' > $path"

【讨论】：

【解决方案2】：

您没有对文件 /usr/local/bin/new_script 或目录 /usr/local/bin 的写入权限

使用 sudo 执行 echo 命令没有帮助，因为 echo 只会写入 stdout 指向的任何文件。问题是外壳打开了您尝试重定向到的文件，该文件仍以普通用户身份运行。

解决方案是确保最终打开和写入文件的进程以 root 身份运行，例如：

echo -e "$content" | sudo dd of="$file"

这会导致 'dd' 以 root 身份运行，并让它打开文件而不是你的 shell 进行写入。

【讨论】：

【解决方案3】：

重定向由当前用户处理，而不是作为根用户。因此，除非当前用户对 $path 有写权限，否则重定向可能会失败。

您可以使用 tee 绕过此限制。例如：

# echo as current user; tee as root
echo -e "$content" | sudo tee "$path"

【讨论】：

【解决方案4】：

您可能没有写信给/usr/local/bin/ 的权限。您正在使用 sudo，但文件重定向 (>) 被应用于 sudo 的输出，而不是 sudo 的命令 (echo)。所以重定向的权限并没有提升。

【讨论】：

仅适用于“sudo'd 命令”的重定向概念不是我确定的，因为这两者之间没有外壳（sudo 直接使用 @ 987654323@ call)，因此它们之间的重定向没有差异。这里没有完全错误，但解释似乎有点令人困惑/误导。