为什么 cron 执行的部分脚本会失败，除非将 stderr 定向到 /dev/null？
以下是我通常从 cron 执行的脚本的片段：
if [ "$RESCAN_COMMAND" = "wipecache" ]; then
log "Linking cover art."
find $FLAC_DIR -name "*.jpg" | while read f; do c=`echo $f | sed -e 's/flac/mp3/g'`; ln -s "$f" "$c"; done
log "Done linking cover art"
fi
从命令行运行时，该脚本可以完美运行。但是，当由 cron （作为同一用户）运行时，它会在 find 行中的某个位置失败。不会记录“完成”消息，并且脚本不会继续超出 if 块。
find 行创建从 flac/Artist/Album/cover.jpg 等文件到 mp3/Artist/Album/cover.jpg 的链接。有数百个文件需要链接。该命令会向 stderr 生成大量输出，因为大多数（如果不是全部）链接已经存在。
凭直觉，我尝试将 ln 命令的 stderr 重定向到 /dev/null：
find $FLAC_DIR -name "*.jpg" | while read f; do c=`echo $f | sed -e 's/flac/mp3/g'`; ln -s "$f" "$c" 2>/dev/null; done
通过此更改，脚本可以从 cron 成功执行（以及从命令行）。
我有兴趣了解原因。
Here is a snippet from a script which I generally execute from cron:
if [ "$RESCAN_COMMAND" = "wipecache" ]; then
log "Linking cover art."
find $FLAC_DIR -name "*.jpg" | while read f; do c=`echo $f | sed -e 's/flac/mp3/g'`; ln -s "$f" "$c"; done
log "Done linking cover art"
fi
The script works perfectly when run from the command line. But when run by cron (as the same user) it fails somewhere in the find line. The "Done" message is not logged and the script does not continue beyond the if block.
The find line creates links from files like flac/Artist/Album/cover.jpg to mp3/Artist/Album/cover.jpg. There are a few hundred files to link. The command generates a lot of output to stderr, because most, if not all, of the links already exist.
On a hunch, I tried redirecting the stderr of the ln command to /dev/null:
find $FLAC_DIR -name "*.jpg" | while read f; do c=`echo $f | sed -e 's/flac/mp3/g'`; ln -s "$f" "$c" 2>/dev/null; done
With that change, the script executes successfully from cron (as well as from the command line).
I would be interested to understand why.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
难道是这个错误报告：https://bugs.launchpad.net/ ubuntu/+源/cron/+bug/151231
Could it be this bug report: https://bugs.launchpad.net/ubuntu/+source/cron/+bug/151231
它可能产生过多的输出。这确实不是一个错误，而是一个功能，因为 cron 通常会发送带有其输出的电子邮件。 MTA 不喜欢有很多行的短信，所以 cron 就退出了。也许无声退出是一个错误。
您还可以使用 ln -f 仅在文件已存在的情况下抑制 ln 错误。
It's probably producing too much output. This really isn't a bug, but a feature as cron typically send emails with it's output. MTA's don't like text messages with many many lines, so cron just quits. Maybe the silent quit is a bug though.
You could also use ln -f to suppress the ln errors in only the case of pre-existing files.