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

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

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