Linux 为什么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（以及从命令行）成功执行

我很想了解原因。
可能是这个bug报告：
可能是这个bug报告：
可能产生了太多的输出。这实际上不是一个bug，而是cron的一个特性，因为cron通常使用它的输出发送电子邮件。MTA不喜欢有很多行的短信，所以cron就退出了。也许沉默的退出是一个错误

您还可以使用ln-f仅在已有文件的情况下抑制ln错误。
这可能会产生太多的输出。这实际上不是一个bug，而是cron的一个特性，因为cron通常使用它的输出发送电子邮件。MTA不喜欢有很多行的短信，所以cron就退出了。也许沉默的退出是一个错误

您还可以使用ln-f来抑制ln错误，这仅适用于预先存在的文件。
谢谢。看起来修复方法是指定一个（空）MTA。我会试试的。谢谢。看起来修复方法是指定一个（空）MTA。我会试试看。我接受这个答案，因为你实际上解释了cron失败的原因，这正是我所要求的。（另外，ln-f比重定向到/dev/null更简洁。我已经修改了脚本来做到这一点。）我接受这个答案，因为您实际上解释了cron失败的原因，这也是我所要求的。（另外，ln-f比重定向到/dev/null更简洁。我已经修改了脚本来做到这一点。）