All in all, very odd, bash continues to be the most bizarre of languages, convoluted, twisted, but with strange solutions thrown in just when you are about to give up hope entirely.” (forum post at Techpatterns )

When re-working a database backup script at one of my customers I stumbled onto the problem that I wanted to have both proper error handling and at the same time avoid filling the disk.

The code providing the challenge was this

$MYSQLDUMP $MYSQLDUMP_OPTS $DB | gzip -9 > $BACKUP_FILE

I need to pipe the output of mysqldump to gzip instead of dumping to an intermediate file that then would be compressed, because otherwise I would fill the disk.

Normally I do error handling in scripts by evaluating $? , but to have proper error handling in here I need to capture the exit value of both mysqldump and gzip. And $? only gives me the exit value of gzip - the least important of the two.

Luckily, and not surprising, I’m not the first person to run into this problem, and by way of googling I found that Bash actually have a built-in way of giving me both exit values - the array $PIPESTATUS . $PIPESTATUS is an array with all the exit values from your last command line. $PIPESTATUS[0] contains the first exit value, $PIPESTATUS[1] the second and so on

sigurdur@ifconfig:~$ true | false sigurdur@ifconfig:~$ echo ${PIPESTATUS[0]} 0 sigurdur@ifconfig:~$ true | false sigurdur@ifconfig:~$ echo ${PIPESTATUS[1]} 1

You can also get the entire array

sigurdur@ifconfig:~$ true | false |false |true sigurdur@ifconfig:~$ echo ${PIPESTATUS[@]} 0 1 1 0

A single, non-piped command is considered to be a “pipe of one”, thus leaving you with a $PIPESTATUS array with one value. Since $PIPESTATUS is updated after every command line I had to copy the array before extracting the exit values. So my code ended up like this:

$MYSQLDUMP $MYSQLDUMP_OPTS $DB | gzip -9 # We want the exit values of both mysqldump and gzip exitarray=("${PIPESTATUS[@]}") mydumpexitcode=${exitarray[0]} gzipexitcode=${exitarray[1]}