Re: backquotes inconsistent with errexit (set -e) and export

[Hans Ecke]

I administer a number of Linux boxen. A large number of shell scripts 
run throughout the day and at night.

Many systems like mine have the disease of the silent decay. Many of the 
scripts have their conditions violated. But nobody ever hears about it. 
At some point you need your backups but *oops* the script didn't do what 
it was supposed to do and nobody noticed.

It is easy to make errors more visible:
1) trap EXIT and output a message if [ $? != 0 ]
2) trap SIG_* and output a message and make sure $? is not 0

But how do we make sure errors propagate outward more reliably? Our only 
solution is 'set -e'.

So you say the current behavior is to spec and you won't fix it.

But do you see my point that it is suboptimal?

> That's because the export command's exit status is 0, regardless of
> what happens while computing its arguments.  This is not the only case
> where -e doesn't mean what we might wish it to mean - a subshell like
> (false) also will not cause the script to exit.  But this is how it's
> specified, and it's not going to change.
>
> Also, -e means subtly different things in different sh
> implementations, so it's more trouble than it's worth for portable
> scripting.  I've given up and switched to inserting "&&" everywhere.

--
Hans Ecke                   hans@ecke.ws / hans@acoustics.mines.edu
Department of Geophysics    http://hans.ecke.ws
Colorado School of Mines    Tel: (USA) 303-273-3733
Golden, Colorado            Fax: (USA) 303-273-3478

Faced with the choice between changing one's mind and proving that there
is no need to do so, almost everyone gets busy with the proof.
                    -- J.K. Galbraith