NetBSD-Bugs archive

[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 <>
To: David Holland <>
Subject: Re: bin/48843: sh(1): break/continue/return broken inside dot commands
Date: Tue, 03 Jun 2014 12:53:56 -0400

 On 2014-06-02 13:54, Richard Hansen wrote:
 > Note that unlike variable binding, the behavior of dynamic scoping of
 > break/continue is a superset of static/lexical scoping (assuming no
 > closures):  If the shell does dynamic scoping of break/continue but
 > scripts are always written assuming lexical scoping then those scripts
 > will still work as expected in all cases.  If POSIX were to specify
 > static/lexical scoping then a shell that performs dynamic scoping would
 > be conformant but with an extension to the standard.
 Oops -- as pointed out in [1] this is incorrect when the argument to
 break/continue is greater than the number of lexically enclosing loops.
  An author could write 'break 1000' to make it obvious to other readers
 that all loops should be broken.  A script like this might behave
 differently on a shell that does dynamic scoping vs. a shell that does
 lexical scoping.
 So it looks like POSIX will probably have to choose either lexical
 (static) or dynamic for the next major version of the standard (Issue 8).
 David voiced his preference for lexical [2]; does anyone else have an
 I think my preference is for dynamic, although I would question the
 design decisions of a script author that takes advantage of dynamic
 scoping.  Why dynamic over lexical?  Because functionality is lost by
 making it lexical:  If a script author wants dynamic but the shell does
 lexical, the author is out of luck.  If the shell does dynamic but the
 author wants lexical, the author can easily count the number of
 lexically enclosing loops and limit the argument of break/continue to
 that value.  Dynamic might also be easier to implement.

Home | Main Index | Thread Index | Old Index