Re: Error handling question

Marc Herbert wrote: > Chet Ramey a écrit : >>> The fact that "set -e" is not the default looks like a big design >>> mistake to me. >> Wow. That ship sailed 30 years ago. > > but forgot "set -e" on the quay? Maybe. But it's 30 years too late to change the default. -- ``The lyf so short, the c

Re: Error handling question

Marc Herbert a écrit : > Chris F.A. Johnson a écrit : >> For example, if you want to know whether user 'john' is in the >> password file: >> >> grep -q ^john: /etc/passwd >> >> You want to get the return code and execute code depending on the result >> >> (which can be 0, 1 or >1; 'if grep

Re: Error handling question

Chet Ramey a écrit : >> The fact that "set -e" is not the default looks like a big design >> mistake to me. > > Wow. That ship sailed 30 years ago. but forgot "set -e" on the quay? See also this ship:

Re: Error handling question

Chris F.A. Johnson a écrit : > It isn't desirable. However, commands will sometimes fail; they > are intended to fail. Their failure provides necessary information > to the script. Because it lacks proper exceptions, the language is indeed creating a confusion between exceptional erro

Re: Error handling question

On Mon, Nov 09, 2009 at 02:43:43PM -0500, Chet Ramey wrote: > > [...] confusing Solaris (quite recent SVR4-like shell) > > with Ultrix (sh: V7-like shell without functions > Solaris's default shell, though more modern than the old Ultrix one, > is not Posix-conformant. Gosh, my "recent" ('88) is

Re: Error handling question

> > With Solaris still shipping a Bourne shell (rather than a POSIX shell) > > in /bin/sh that means you're stuck with 7th Edition semantics unless > > you're willing to put in tricks to try to re-invoke your script under > > /usr/xpg4/bin/sh or /bin/sh5 or ksh or bash or whatever. > > Such dicuss

Re: Error handling question

On Mon, Nov 09, 2009 at 09:10:02AM -0500, Greg Wooledge wrote: > On Mon, Nov 09, 2009 at 03:49:09PM +0200, Ciprian Dorin, Craciun wrote: > > P.S.: The fact that some features of Bash, mainly `set -e`, which > > should be a safety-net for scripts, is "unpredictable" is not so very > > reassurin

Re: Error handling question

> The fact that "set -e" is not the default looks like a big design > mistake to me. Wow. That ship sailed 30 years ago. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnsw

Re: Error handling question

On Mon, 9 Nov 2009, Marc Herbert wrote: > Greg Wooledge a ?crit : > > > The problem being "how to use set -e in a consistent manner across all > > shells"? You can't. set -e is unpredictable, unreliable, and should be > > shunned. As you can see by the last dozen or so message on this mailing

Re: Error handling question

Greg Wooledge a écrit : > The problem being "how to use set -e in a consistent manner across all > shells"? You can't. set -e is unpredictable, unreliable, and should be > shunned. As you can see by the last dozen or so message on this mailing > list, not even bash gurus (other than Chet) can

Re: Error handling question

Ciprian Dorin, Craciun wrote: >>Sorry, but I don't understand at all... So please bare with me and >> make me understand. >> >>So I've interpreted `set -e` as a way to tell bash to treat any >> process exiting with non-zero (and not succeeded by a || ), as an >> error and end the current s

Re: Error handling question

On Mon, Nov 09, 2009 at 03:49:09PM +0200, Ciprian Dorin, Craciun wrote: > Unfortunately I'm not subscribed to this mailing list. Could you > point me to the right thread? http://lists.gnu.org/archive/html/bug-bash/2009-11/threads.html And... pretty much every month, especially since bash 4 ch

Re: Error handling question

> Sorry, but I don't understand at all... So please bare with me and > make me understand. > > So I've interpreted `set -e` as a way to tell bash to treat any > process exiting with non-zero (and not succeeded by a || ), as an > error and end the current shell / sub-shell. Close. There a

Re: Error handling question

On Mon, Nov 9, 2009 at 3:37 PM, Greg Wooledge wrote: > On Mon, Nov 09, 2009 at 08:39:57AM +0200, Ciprian Dorin, Craciun wrote: >>     But then how can I solve the problem? (How about `()` which >> clearly is a new shell instance.) > > The problem being "how to use set -e in a consistent manner acr

Re: Error handling question

On Mon, Nov 09, 2009 at 08:39:57AM +0200, Ciprian Dorin, Craciun wrote: > But then how can I solve the problem? (How about `()` which > clearly is a new shell instance.) The problem being "how to use set -e in a consistent manner across all shells"? You can't. set -e is unpredictable, unreli

Re: Error handling question

On Mon, Nov 9, 2009 at 8:35 AM, Jan Schampera wrote: > Ciprian Dorin, Craciun schrieb: > >>     Thus if I say: `set -e ; { false ; true ; }` it works, but when I >> put the `||`, it doesn't... > > I think it's because { ...; } isn't a simple command (however, its > components are). > > J. Bu

Re: Error handling question

On Mon, Nov 9, 2009 at 8:23 AM, Ciprian Dorin, Craciun wrote: > On Mon, Nov 9, 2009 at 4:49 AM, Chet Ramey wrote: >> Ciprian Dorin, Craciun wrote: >>>     Shouldn't any of the following scripts print `error`? (Bash >>> 4.0.35(2)-release on ArchLinux.) >>> >>>     Or I've miss-interpreted the docu

Re: Error handling question

Ciprian Dorin, Craciun schrieb: > Thus if I say: `set -e ; { false ; true ; }` it works, but when I > put the `||`, it doesn't... I think it's because { ...; } isn't a simple command (however, its components are). J.

Re: Error handling question

On Mon, Nov 9, 2009 at 4:49 AM, Chet Ramey wrote: > Ciprian Dorin, Craciun wrote: >>     Shouldn't any of the following scripts print `error`? (Bash >> 4.0.35(2)-release on ArchLinux.) >> >>     Or I've miss-interpreted the documentation... >> >>     Thanks, >>     Ciprian. >> >> >> >> set -e

Re: Error handling question

Ciprian Dorin, Craciun wrote: > Shouldn't any of the following scripts print `error`? (Bash > 4.0.35(2)-release on ArchLinux.) > > Or I've miss-interpreted the documentation... > > Thanks, > Ciprian. > > > > set -e -o pipefail > ( false ; echo ok ; ) || echo error > >