Re: triggering of ERR trap differs between bash 3.2.39 & 4.0.28

Seems like I've erroneously switched between bash versions exhibiting the difference. It's 3.2.39 that evaluates 'on_error' when catching the trap. From the start: # bash-4.0_p28/image/bin/bash --version GNU bash, version 4.0.28(2)-release (x86_64-pc-linux-gnu) Copyright (C) 2009 Free Software

Re: Test -a and -e

Chet Ramey schrieb: >> Code: >> $ [ ! -a /bin/bash ] && echo "Doesn't exist"; [ -a /bin/bash ] && echo >> "Exists" >> >> Output: >> Doesn't exist >> Exists > Please read the Bash FAQ, question E1. The behavior of test depends on > the number of arguments; the rules are in the manual page. > >

Re: [PATCH] silent job monitor when 'set +m'

Chet Ramey schrieb: > redirect stderr > kill pid > wait pid > restore stderr > > It seems to me that this sequence forces the necessary synchronicity. Interesting. And sad that I never thought of that. Jan

Re: Test -a and -e

Jan Schampera wrote: > Hello list, > > Code: > $ [ ! -e /bin/bash ] && echo "Doesn't exist"; [ -e /bin/bash ] && echo > "Exists" > > Output: > Exists > > > Code: > $ [ ! -a /bin/bash ] && echo "Doesn't exist"; [ -a /bin/bash ] && echo > "Exists" > > Output: > Doesn't exist > Exists > > > It

Test -a and -e

Hello list, Code: $ [ ! -e /bin/bash ] && echo "Doesn't exist"; [ -e /bin/bash ] && echo "Exists" Output: Exists Code: $ [ ! -a /bin/bash ] && echo "Doesn't exist"; [ -a /bin/bash ] && echo "Exists" Output: Doesn't exist Exists It seems there's a difference between -a and -e, though they are

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: [PATCH] silent job monitor when 'set +m'

> > It doesn't require a subshell to save and restore stderr. > > At first I thought the same. And then I read this: > > > > It's also useless to temporarily redirect stderr when you call the > kill command, since

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: [PATCH] silent job monitor when 'set +m'

Chet Ramey a écrit : >>> Sure. Since the status messages are written to stderr, you can save >>> file descriptor 2 and temporarily (or permanently, depending on your >>> needs) redirect it to /dev/null. >>> >> That means another subshell. > > It doesn't require a subshell to save and restore stde

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: triggering of ERR trap differs between bash 3.2.39 & 4.0.28

> Ok. Same here. (4.0.35 is not yet stable on my distro, gentoo, hence I > quoted results with 4.0.28). But I can't reproduce it with bash-4.0.28, either: $ ./bash --version GNU bash, version 4.0.28(2)-release (i386-apple-darwin9.8.0) Copyright (C) 2009 Free Software Foundation, Inc. License GPL

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: [PATCH] silent job monitor when 'set +m'

> > Sure. Since the status messages are written to stderr, you can save > > file descriptor 2 and temporarily (or permanently, depending on your > > needs) redirect it to /dev/null. > > > > That means another subshell. It doesn't require a subshell to save and restore stderr. -- ``The lyf so s

Re: [PATCH] silent job monitor when 'set +m'

On Mon, Nov 9, 2009 at 10:42 AM, Chet Ramey wrote: > Sure. Since the status messages are written to stderr, you can save > file descriptor 2 and temporarily (or permanently, depending on your > needs) redirect it to /dev/null. > That means another subshell. Thanks for all your help. Jeff.