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). I'm wondering: CHANGES doesn't refer to any bug numbers or anything. Isn't bash using some issue-tracking framework? I suppose this issue falls under: l. Changed behavior of shell when -e opti

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

Amit Dor-Shifer wrote: > cm.stargate ~ # bash -xc 'set -eE;on_error() { echo ERROR ERROR; };trap > on_error ERR;if [ -n "$(echo $0 |grep a)" ];then echo "input contains > 'a'";fi' b > + set -eE > + trap on_error ERR > ++ echo b > ++ grep a > +++ on_error > +++ echo ERROR ERROR > + '[' -n 'ERROR ER

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 > >

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

Jeff Chua wrote: > Revisited. The previous reply to your example works fine for interactive > shell. But for a script (non-interactive shell), the example does not > work the same. Job status are always reported even with "set +m" in the > script. ... Right. This is part of my previous answer,

Error handling question

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 set -e -o pipefail ( false ; echo ok ; ) | true || e

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

Amit Dor-Shifer wrote: > I've the following script: > > set -eE > on_error() { echo ERROR ERROR; } > trap on_error ERR > > if [ -n "$(echo $1 |grep a)" ];then >echo "input contains 'a'" > fi > > When executed under bash-4, on_error is evaluated as part of the > expression in the 'if'. This

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

> On Sun, Nov 8, 2009 at 5:25 AM, Chet Ramey wrote: > non-interactive shells don't have job control enabled by default. Are you saying > you ran a script in which you enabled job control, ran a job, turned job control off, > then killed the job? > Bash and historical versions of sh report the

triggering of ERR trap differs between bash 3.2.39 & 4.0.28

I've the following script: set -eE on_error() { echo ERROR ERROR; } trap on_error ERR if [ -n "$(echo $1 |grep a)" ];then echo "input contains 'a'" fi When executed under bash-4, on_error is evaluated as part of the expression in the 'if'. This does not happen in 3.2: amit0 ~ # bash --ve

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

On Sun, Nov 8, 2009 at 10:14 AM, Chet Ramey wrote: > I think you're confused about the distinction. set -m and +m turn job > control on and off. The `monitor' name is historical (ask Dave Korn > why he chose it). > That's what confused the whole issue. > What version of bash are you using?