[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: why does errexit exist in its current utterly useless form?
From: |
matei . david |
Subject: |
Re: why does errexit exist in its current utterly useless form? |
Date: |
Sat, 15 Dec 2012 08:54:22 -0800 (PST) |
User-agent: |
G2/1.0 |
On Friday, December 14, 2012 6:23:41 PM UTC-5, Eric Blake wrote:
> Short answer: historical compatibility. 'set -e' has been specified to
> behave the way it did 30 years ago in one reference implementation, and
> while you can argue till you are blue in the face that the reference
> implementation is not intuitive, you have to at least appreciate that
> having a standard means you are likely to get the same (non-intuitive)
> behavior among several competing shell implementations that all strive
> to conform to POSIX.
Thanks for the reply. I understand the benefits of a standard. In this case, it
seems to me that the problem we're talking about- stopping a script as soon as
a command returns an unexpected non-0 code- is a very basic feature that many
could benefit from, if implemented right. I'm trying to understand whether or
not fixing this problem requires changing the standard or not.
My question 5 is about whether the standard itself requires that subsequent
attempts to set errexit should be ignored, even assuming that errexit should be
turned off once in a while for the sake of the standard. The alternative is
that this is just a historical decision of bash that could be mended without
breaking compliance.
If indeed the standard requires all further attempts to set errexit be ignored
(which I think is a terrible idea), wouldn't it be a good idea to provide in
bash another option doing the same thing, but correctly? Something like set -o
strong_errexit, something that anybody writing a new script can choose to use
or not, of course understanding that it is a bashism, but the right kind of
bashism.
Also, my questions 1-3 relate to the current implementation...