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

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, May 31, 2014 at 05:14:26PM -0400, Richard Hansen wrote:
 > > 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.

Offhand, I would say that continues and breaks should be statically
scoped; dynamic scoping is almost always a mistake. So you certainly
shouldn't be able to break from a loop by calling a function that
contains a break outside a loop. (Although netbsd's sh, bash, and zsh
all seem to allow this, I would call it a bug. ksh rejects it.)

How this applies to a sourced file isn't so clear though, at least
offhand, as the point of sourcing a file is to read and evaluate it
within the current context. My inclination would be that sourcing a
file is not the same as calling a function; however, I'm far from an
expert on sh.

It seems that the behavior of sourcing with respect to $0 and $@
varies among implementations, which doesn't make me happy.

 > 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.

netbsd's sh seems to accept it silently; ksh, bash, and zsh all reject
it. I would consider our sh broken.

 > > 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?

With stuff like this, I'd rather fix our implementation (or have it be
noncompliant until fixed) than standardize unprincipled behavior. FWIW.

-- 
David A. Holland
dholland%netbsd.org@localhost