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

[Jarmo Jaakkola <jarmo.jaakkola%roskakori.fi@localhost>]

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

From: Jarmo Jaakkola <jarmo.jaakkola%roskakori.fi@localhost>
To: Richard Hansen <rhansen%bbn.com@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: Sun, 1 Jun 2014 02:09:41 +0300

 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.
 
 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.  How about local
 variables, or were they just a common extension that is not specified
 in POSIX?
 
 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.
 
 > > 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?
 
 I have no opinion one way or another.  I just took the easiest way to fix
 existing breakage.  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.
 
 > 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.
 Quick check for other shells: bash and zsh work the same, ksh complains and
 does not break the loop nor return from the function.
 
 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.
 
 > > +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...").
 
 I agree, that would be better.  Perhaps:
 
     The POSIX standard is unclear on how loop control keywords (break
     and continue) behave across a dot command boundary.  This
     implementation (currently) allows them to control loops surrounding
     the dot command.
 
 > > +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..."
 
 Yes, of course, my bad.  Your formulation would be better.
 
 christos, you made the previous commits, could you do those language
 tweaks?  Or should I prepare another patch?
 
 -- 
 Jarmo Jaakkola