Re: bin/48843: sh(1): break/continue/return broken inside dot commands

[Richard Hansen <rhansen%bbn.com@localhost>]

The following reply was made to PR bin/48843; it has been noted by GNATS.

From: Richard Hansen <rhansen%bbn.com@localhost>
To: jarmo.jaakkola%roskakori.fi@localhost
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%netbsd.org@localhost, 
 tech-userlevel%NetBSD.org@localhost
Subject: Re: bin/48843: sh(1): break/continue/return broken inside dot commands
Date: Sat, 31 May 2014 17:14:26 -0400

 > According to the POSIX standard, this is how it should work:
 >     dot:
 >         The shell shall execute commands from the file in the current
 >         environment.
 >     break:
 >         The break utility shall exit from the smallest enclosing for, while,
 >         or until loop, [...]
 >     continue:
 >         The continue utility shall return to the top of the smallest
 >         enclosing for, while, or until loop, [...]
 >     return:
 >         The return utility shall cause the shell to stop executing
 >         the current function or dot script.  If the shell is not currently
 >         executing a function or dot script, the results are unspecified.
 > 
 > It is clear that return should return from a sourced file,
 
 Yes.
 
 > Whether break and continue should work from the sourced
 > file might be debatable.  Because the dot command says "in the current
 > environment", I'd say yes.
 
 Not necessarily.  POSIX does not define "enclosing loop", so it could be
 interpreted as syntactic enclosure (a break/continue command must be a
 command in the compound list associated with the loop for the loop to
 qualify as enclosing the command) or logical enclosure as experienced
 during execution.  I can see pros and cons to either behavior.
 
 I will bring this up during the next Austin Group teleconference.  We
 should be able to get some improved wording in before POSIX Issue 7 TC2
 is published (even if that wording is simply "unspecified" or
 "implementation defined").  Any input from the NetBSD community would be
 appreciated.
 
 The intended behavior of break/continue outside of a loop is also
 unclear.  I'll bring that up as well.
 
 > Because I read the standard to mean that break and continue should have
 > an effect outside the sourced file, that's how I implemented it.  For what
 > it's worth, this also seems to be what bash does.
 
 The behavior of existing implementations will strongly influence the
 direction the Austin Group takes when revising the text.  With that
 said, what behavior would you like POSIX to specify?
 
 Sourcing a file with the dot command and running a function are very
 similar; how do your changes affect how the shell behaves when calling a
 function that has break/continue in the body?
 
 > +A non-obvious consequence of the file executing in the current environment
 > +is that loop control keywords (continue and break) can be used in the file
 > +to control loops surrounding the dot command.
 
 Specifying this new behavior in the man page implies commitment to it.
 In case you want to change the behavior in the future (perhaps because
 the Austin Group standardizes a different behavior), I would recommend
 softening the language like you did with 'return' (e.g., "the POSIX
 standard is unclear, so this implementation (currently) does...").
 
 > +The effects of using a return command outside a function or a dot command
 > +are not standardized.
 
 One can argue that the effects are standardized as "unspecified".  :)
 
 How about: "The POSIX standard says that the results of running 'return'
 outside a function or dot script are unspecified.  This implementation..."
 
 Thanks,
 Richard