On ven, 2008-03-28 at 15:58 +0100, John Hughes wrote: > So it would be simpler to get rid of the "pidof splashy" call: > > splashy_update "scroll $1: $2" 2>/dev/null || true
> But doing some tests it looks like most (all?) shells don't treat a > command that contains && as an error: > > $ cat zztest > set -e > pidof noprog && echo "noprog running" > echo no error > $ sh -x zztest > + set -e > + pidof noprog > + echo no error > no error > > > Maybe there is some other problem? > > Maybe it's splashy_update that's failing? man "set" : -e When this option is on, if a simple command fails for any of the reasons listed in Consequences of Shell Errors or returns an exit status value >0, and is not part of the compound list fol‐ lowing a while, until, or if keyword, and is not a part of an AND or OR list, and is not a pipeline preceded by the ! reserved word, then the shell shall immediately exit. http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_08_01 So the behaviour for AND or OR list is not obvious for me ... for example : set -e false && true echo "no error" returns : "no error". by the way : false && false also returns "no error" so what kills the script is not the exit status in a list ... So basically I agree && does not trigger an error . What I found out is that inside a function the behaviour changes : set -e a() { false && true } a; echo "no error" fails while : set -e a() { false && true || true } a; echo "no error" succeed. So my patch seems needed to get things working as lsb-base-logging.sh make the list of calls in functions. Best regards Alban -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]