Bash中echo命令无显式重定向时是否会输出到stderr？

核心疑问 #

许多命令（比如wc --wrong-flag）会向stderr输出内容，但echo是否属于这类命令？

背景场景 #

我正在维护一段Bash脚本，其中有如下片段（已做安全脱敏）：

log_file_path="logs/some_prefix_redacted.$(date +%Y-%m-%d_%H_%M_%S).log"
echo "Running Step 1 - Deleting files from S3 recursively" >> "${log_file_path}" 2>&1
aws s3 rm --recursive s3://s3_path_redacted >> "${log_file_path}" 2>&1
step_1_exit_code="${?}"
echo "Step 1 - Deleting files from S3 recursively finished with exit code ${step_1_exit_code}." >> "${log_file_path}" 2>&1

我想知道echo命令末尾的2>&1是否有必要——我们的目标是a) 保留尽可能多的调试信息；b) 精简代码，不写无用操作。

具体疑问拆解 #

1. echo本身会不会在无显式重定向的情况下向stderr输出内容？
   我测试过，如果把echo的stdout或stderr重定向到无写入权限的文件，会触发错误输出到常规stderr，但不确定无重定向时是否会出现这种情况。

2. 如果echo执行失败该怎么处理？
   比如因权限不足无法写入日志文件时：

   $ echo "This won't work" > /root/not_allowed 2>&1
   bash: /root/not_allowed: Permission denied
   $ echo "${?}"
   1
   # 奇怪？我没往stderr写内容，但命令还是失败了？
   $ echo "Will this work?" 2>/root/not_allowed
   bash: /root/not_allowed: Permission denied
   

   我希望能捕获这类脚本执行失败的情况，比如在脚本开头先尝试用echo写入日志，若失败则发送邮件或Slack通知。

额外考量 #

我曾考虑改用Python编写脚本，因为它的异常处理更完善，但Python无法保证一定能启动——可能存在版本不兼容、LD_LIBRARY_PATH配置错误等问题。相比之下，Bash在主流Linux系统上几乎都存在，可靠性更高，但错误检查和复杂度管理不如Python。

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