On Mon, 25 Oct 2010 17:11:19 -0400, micah anderson <mi...@riseup.net> wrote:
> On Mon, 25 Oct 2010 16:05:12 -0400, Jameson Rollins 
> <jroll...@finestructure.net> wrote:
> > Let's say I'm writing a bash script.  It will make 5 calls.  Three of
> > the calls are expected to return zero on success, one is expected to
> > return 1 on success, and one whose return code I don't care about.
> > Here's this script written with set -e:
> > 
> > #!/bin/bash
> > set -e
> > call0
> > call1
> > call2
> > call3 || ret=$?
> > if ((ret != 1)); then
> >    exit 1
> > fi
> > call4 || true
> 
> imagine that line 2 of the script is this: 
> 
> let i=$i+1 
> 
> set -e FAILS and because this script was designed to protect your life,
> you perish.  The end.
> 
> Now imagine that your script says this instead:  
> 
> call0 || die
> 
> oh no!
> 
> Now imagine that your script says this instead:  

Now imagine its three years from now. The POSIX definition of this
feature changes, yet again, as it has been doing often. The next version
of Bash tries its best to track this change, but results in your 'set
-e' doing something different than you expect. Now we are sad because
this change causes our heads to get lopped off, which wouldn't have
happened because we explicitly handled our own error checking.

Attachment: pgp6Vxrb6KsiL.pgp
Description: PGP signature

Reply via email to