[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/48843: sh(1): break/continue/return broken inside dot commands
The following reply was made to PR bin/48843; it has been noted by GNATS.
From: David Holland <dholland-tech%netbsd.org@localhost>
To: Richard Hansen <rhansen%bbn.com@localhost>
Cc: jarmo.jaakkola%roskakori.fi@localhost, gnats-bugs%NetBSD.org@localhost,
Subject: Re: bin/48843: sh(1): break/continue/return broken inside dot
Date: Sat, 31 May 2014 23:51:35 +0000
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
> 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
Main Index |
Thread Index |