bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Doc of "set -e" should mention non-locality


From: Dan Douglas
Subject: Re: Doc of "set -e" should mention non-locality
Date: Thu, 05 Jul 2012 10:55:48 -0500
User-agent: KMail/4.8.3 (Linux/3.4.2-pf+; KDE/4.8.3; x86_64; ; )

On Wednesday, July 04, 2012 05:37:25 PM Rainer Blome wrote:
> -------- Original-Nachricht --------
> > Datum: Fri, 29 Jun 2012 18:03:13 -0500
> > Von: Dan Douglas <ormaaj@gmail.com>
> > An: bug-bash@gnu.org
> > CC: Rainer Blome <rainer.blome@gmx.de>
> 
> Remember that my main suggestion is to clearly document the intended
> behavior (see the subject). This could mean to add a generic
> paragraph to the documentation of "set" that describes the scope
> and extent for all options. 

I'm all for better documentation. Scope in Bash is a complex subject. Almost 
none of it is documented, and there is little standardization around how 
function scope is supposed to work anyway. I'd call set -e a low priority 
relative to documenting what scope behaviors are actually in place.

> > On Thursday, June 28, 2012 02:37:17 PM Rainer Blome wrote:
> > > The implementation of "set -e" does not respect "lexical nesting".
> > > This can be very surprising.  
> > 
> > None of the "set" options do, nor does the ERR trap.
> 
> That may very well be. Is this documented anywhere?

About the one thing you can count on with regards to scope in Bash, is that it 
won't be lexical. But that's true of the majority of shells that have any kind 
of scoping features at all beyond positional parameters and environment 
variables.

> PS: Your suggested "workaround" is, well, hard to understand.
> Reminds me of the way people extend FORTH by massaging the stacks.
> You have to know exactly what is parsed, substituted and evaluated
> when in order to understand this (if it even works, did not try it).
> I would not dare use this in production for fear of
> receiving a beating from colleagues over hard to maintain code. ;-)

That's basically what it is (and this is yet another an undocumented scope 
thing). Setting this trap within a function sets a hook on the function and 
all of its callers which essentially runs eval on the given string upon 
returning. To make matters more confusing, also potentially on callees if they 
have the trace attribute set.

Other than that there's not much to understand or maintain. It'll set -e when 
returning from the first function and set +e when returning from the second, 
then unset itself on any further callers.

> > Here's a workaround (untested).
> > 
> > sete() {
> >     [[ $- == *e* ]]  && return 1
> >     trap "$(</dev/stdin)" RETURN
> > } <<EOF
> > if [[ $FUNCNAME != \$FUNCNAME ]]; then
> >     set +e
> >     trap - RETURN
> > else
> >     set -e
> > fi
> > EOF
> > 
-- 
Dan Douglas

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]