Question

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.

Answer 1

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.