[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: set -e yet again (Re: saving bash....)

From: Greg Wooledge
Subject: Re: set -e yet again (Re: saving bash....)
Date: Fri, 12 Aug 2011 11:37:32 -0400
User-agent: Mutt/

On Fri, Aug 12, 2011 at 08:18:42AM -0700, Linda Walsh wrote:
>       If I write a==0 on the bash command line, it will generate an error.
> a=0 does not.  'Bash' knows the difference between an assignment and a
> equality test in math.

imadev:~$ ((a==0))
imadev:~$ ((a=0))
imadev:~$ a==0
imadev:~$ a=0

They all mean something different, but they are all valid commands.
Do I need to explain what each one does?

> Maybe that's the 'compatible "out", we are, perhaps, all looking for.

I am not looking for anything.  You, on the other hand, appear to be
looking for something... I'm not sure what.  Some sort of argument you
can produce which will make EVERY programmer in the rest of the world say
"Wow, you're right, we should throw away 30 years of compatibility and
make set -e work like you expect!!" maybe?

I'm fairly confident this will not happen.

Maybe you just want Chet to accept your argument that he should ignore
POSIX and follow the Walsh Standard For Bash instead?  That's somewhat
less impossible, I guess.  I won't speak for him.

> >A wiser
> >programmer would skip the set -e (knowing how fallible and cantankerous
> >it is), and check cd's success directly:
> >
> >  cd /foo || exit
> >  rm -rf bar

> Right, and as you are developing, you don't right your first code
> cd /foo && rm -fr bar?

I only showed two lines.  In most programs, there would probably be
several commands following the cd and the rm.  The rm depends on the
cd having succeeded.  The third command depends on the cd having
succeeded, and may also depend on the rm having succeeded, and so on.
If the cd fails, you can pretty much guarantee the whole thing's
going pear-shaped, so exiting immediately is a decent resolution.  If
the rm fails, your application may still be able to function.  (Well,
the -f means it *shouldn't* actually fail, but you get the point, I
hope.)  So if you need to check the result of the rm and do something
less drastic than "exit", you can do that.

> if the 'rm' fails I'd expect it to die...

Because you use set -e.  I do not.  I would not expect a script to die
if an rm command fails.  I would expect the script to carry on.  If I
want the script to take action in the event of an rm command's failure,
I will *add error-checking*.  I will make it do whatever is appropriate,
which may be exiting, or returning from a function, or setting a variable
to indicate "don't bother" later on, or printing a message into a log
file, or who knows.

> I won't have an error check in a first script that comes from doing it 
> 'interactively,
> bash line-re-edits, that are later saved as a script.
> Scripts born that way are just 'batch jobs' that need to be turned into 
> full on
> error checked scripts.

Not all of us work that way.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]