[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: Richard Hansen <rhansen%bbn.com@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%netbsd.org@localhost,
Subject: Re: bin/48843: sh(1): break/continue/return broken inside dot commands
Date: Sat, 31 May 2014 17:14:26 -0400
> According to the POSIX standard, this is how it should work:
> The shell shall execute commands from the file in the current
> The break utility shall exit from the smallest enclosing for, while,
> or until loop, [...]
> The continue utility shall return to the top of the smallest
> enclosing for, while, or until loop, [...]
> The return utility shall cause the shell to stop executing
> the current function or dot script. If the shell is not currently
> executing a function or dot script, the results are unspecified.
> It is clear that return should return from a sourced file,
> 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.
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.
> 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?
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?
> +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...").
> +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..."
Main Index |
Thread Index |