Shell script doesn't paint last line of stdout to screen without user input

Question

I have a shell script that's happily doing all my backup process and writing progress to stderr and stdout, with one exception — the last line doesn't get written to my terminal (if I call the script manually) until I hit Enter.

Now this isn't a big deal, but it's really irritating me that it's not doing it, so I'd like to understand why it's behaving that way.

What gets written to the output (after I hit Enter) reads:

[blackero@XXXXXXXXXXXXXXXX ~]$ fullbackup.sh
Tue Feb 28 17:57:41 GMT 2012
Tue Feb 28 17:57:41 GMT 2012
Starting SITE_NAME backup
maintenance_mode was set to 1.                                                    [success]
/home/blackero/bin/fullbackup.sh: line 36: hash: lzma: not found
maintenance_mode was set to 0.                                                    [success]

Backup for SITE_NAME created


[blackero@XXXXXXXXXXXXXXXX ~]$

The relevant parts of the script read as follows (with ↪ indicating I've wordwrapped the code for legibility):

#!/bin/bash
date
date 2>&1

# [A bunch of content has been deleted from here]

# Compress with lzma if available, otherwise use gzip
if hash lzma; then
  lzma -c ${backup_dest}/${dbname} >${backup_dest}/${dbname}.lzma
  ↪  && rm ${backup_dest}/${dbname}
else
  gzip -c ${backup_dest}/${dbname} >${backup_dest}/${dbname}.gz
  ↪  && rm ${backup_dest}/${dbname}
fi

# Disable maintenance mode.
drush -r ${drupal_root} vset --always-set maintenance_mode 0

# Remove old backups >30 days
find ${backup_dest} -mtime +30 -exec rm {} \; >> /dev/null 2>&1

echo "Backup for ${sitename} created"
echo
echo 2>&1

So, you can see the if hash lzma; then line that's causing the hash: lzma: not found line to stderr (it'd be nice if I could suppress this message, so it doesn't write that warning, but I can live with it). You can see that drush is writing the maintenance_mode was set to 0. line to stdout. But the line Backup for SITE_NAME created only appears once I hit Enter.

Is that because the previous command is redirecting stdout to /dev/null? Do I need to undo that redirect somehow? (I thought stream redirection only affected the single command atomically.)

(Caveats: Fwiw, when this script is run from cron, with stdout and stderr redirected to append to logfiles, everything gets written to the logfiles quite happily, with no terminal input required. The script is originally from Drupal's Administration Guide: fullsitebackup_drush; I've edited it a fair amount, but the lzma or gzip code is from there.)

Answer 1

If your backup files are read-only, it's possible that the rm command run by find is prompting you to confirm whether or not it should delete a backup file. You can't see the prompt because you redirected it to /dev/null. The Enter you press is read by rm (and makes rm take the default answer, which is not to delete the file).

If this hypothesis is correct you can fix the problem in one of two ways. One is portable but insecure, the other is nonportable but more secure. Even though in this case the security difference is likely small (since attackers probably can't create symlinks in ${backup_dest}) I'll suggest both options:

secure:

find "${backup_dest}" -depth -mtime +30 -delete

portable:

find "${backup_dest}" -depth -mtime +30 \
  '(' '(' -type d -exec rmdir {} \; -true ')' -o -exec rm -f {} \; ')'

Last, there is no need to use ">> /dev/null" instead of "> /dev/null" since there's no difference between appending to a character device and writing to it, since character devices are not seekable.