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: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%netbsd.org@localhost, 
 tech-userlevel%NetBSD.org@localhost
Cc: 
Subject: Re: bin/48843: sh(1): break/continue/return broken inside dot commands
Date: Mon, 02 Jun 2014 13:21:17 -0400

 On 2014-05-31 19:09, Jarmo Jaakkola wrote:
 > On Sat, May 31, 2014 at 05:14:26PM -0400, Richard Hansen wrote:
 >> 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.
 
 I filed a bug report that will be the basis for discussion during the
 Thursday teleconference (assuming we have time to address this bug):
 http://austingroupbugs.net/view.php?id=842
 
 > 
 > That would be great, these things really should be clarified.  This
 > probably belongs to "shell execution environment"?  That is, whether
 > function and loop nesting levels are part of it or not.
 
 I'll think about it more when I write up the proposed changes, but I
 don't think that the Shell Execution Environment section is the
 appropriate place.  That section is all about how the shell forks (or
 the equivalent) to run commands.  The purpose of the "in the current
 environment" phrase in the dot command's description is to let you know
 that the script isn't run in a subshell or as a separate process, so it
 can modify variable assignments, etc.
 
 If dot was meant to act like C's #include and read a separate file's
 lines as if they were typed where the dot command was typed, then I
 think it would have been specified that way.
 
 > How about local
 > variables, or were they just a common extension that is not specified
 > in POSIX?
 
 Local variables are a common extension.  Proposing text to standardize
 local variables is on my todo list -- they would help solve some really
 problematic parts of the current standard.  See [1] and the discussion
 at [2].
 
 I should note that anyone is welcome to submit bug reports or proposed
 wording changes about any topic.  You can even join the next POSIX
 telecon if you'd like; see [3].
 
 [1] http://austingroupbugs.net/view.php?id=654
 [2] http://thread.gmane.org/gmane.comp.standards.posix.austin.general/6728
 [3] http://article.gmane.org/gmane.comp.standards.posix.austin.general/9454
 
 > 
 > While we're on the subject of clarity, I'm not sure if the value $0
 > inside a dot command has been specified.  It could be implied by
 > "current execution environment" but perhaps it wouldn't hurt to be
 > explicit.
 
 The value of $0 in a dot script is specified -- it is the same as it was
 before the script was sourced.  This is not explicit -- the only way to
 arrive at this conclusion is to note that the description of the dot
 command does not specify any change to $0.  It would be better if this
 was made explicit, as it is with functions.  I'll add that to my todo
 list, or you can file a bug report if you'd like.
 
 >> 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?
 > 
 > I have no opinion one way or another.  I just took the easiest way to fix
 > existing breakage.
 
 OK
 
 > I quickly tested with bash, ksh and zsh with a trivial
 > case: dot command in a while loop contains a break. bash does as my change
 > does: the loop is broken.  ksh complains and seems to ignore the break.
 > zsh's behaviour is probably best described as "undefined", because it
 > complains, stops sourcing the file and yet does not break the loop.
 
 Curious -- I had different results when testing 'break' from a dot
 script in other shells (I documented my results in the POSIX bug report).
 
 > 
 >> 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?
 > 
 > My changes retain the previous behavior, which was to allow a break or
 > a continue in function to affect a loop that contains the function call.
 
 So the behavior from a function and the behavior from a dot script are
 now the same?  I like that.
 
 > Quick check for other shells: bash and zsh work the same, ksh complains and
 > does not break the loop nor return from the function.
 
 Hmm, my test results differed from yours in the function case as well as
 the dot script case.  (Not that it matters much.)
 
 > 
 > How the function call worked was one more reason I chose to implement
 > the dot command fix as I did: one could think this implementation of
 > a dot command as a function call that has no parameters (except "set --")
 > and that the function's body is stored in a file.
 
 Exactly -- I think it's good for those two cases to be consistent.
 
 -Richard