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

[Rhialto <rhialto%falu.nl@localhost>]

The following reply was made to PR bin/48843; it has been noted by GNATS.

From: Rhialto <rhialto%falu.nl@localhost>
To: David Holland <dholland-tech%netbsd.org@localhost>
Cc: Richard Hansen <rhansen%bbn.com@localhost>, 
jarmo.jaakkola%roskakori.fi@localhost,
        gnats-bugs%NetBSD.org@localhost, tech-userlevel%NetBSD.org@localhost
Subject: Re: bin/48843: sh(1): break/continue/return broken inside dot
 commands
Date: Sun, 1 Jun 2014 23:19:17 +0200

 --nmemrqcdn5VTmUEE
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Sat 31 May 2014 at 23:51:35 +0000, David Holland wrote:
 > On Sat, May 31, 2014 at 05:14:26PM -0400, Richard Hansen wrote:
 >  > 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.
 >=20
 > 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.)
 
 I agree. The other way is clearly unworkable. A function with a break or
 continue outside a loop would be incorrect to call except inside a loop.
 That is ludicrous.
 
 > 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.
 
 I would say here too that static checking should be the norm. Except
 that there is an inherent non-staticness here: the file could have been
 generated dynamically, or the name of the file could be dynamic, or
 perhaps even more annoying non-static things.
 
 -Olaf.
 --=20
 ___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
 \X/ rhialto/at/xs4all.nl    -- 'this bath is too hot.'
 
 --nmemrqcdn5VTmUEE
 Content-Type: application/pgp-signature
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQEcBAEBAgAGBQJTi5jUAAoJEJmJxkVhw/vTnnoH/05oc9bPyvEB1mN1UeCxaLZj
 n9/fE+KfnguYZq1bZC9kL8nFwvddXdq/NVEDpP67Ie7dvyfSsblK1VYYpP0/+ETX
 ITUZFt/iiCsg+wLlejmSD08pWzNaNHBPA4YMe6wX7N/XaL8JWaFZt+0XUW/cRAPE
 lRN8H/fzOri5rins4++/NEY30/3Bubw1xUhx7I+mjy1Rjrv3BBpQxA0eEb8n+/Hy
 /W2zzXX79AB1uKSLGxJD8k5oAIFy0Zi4QIfc2qZ7HziJ1AWn/hCuhIrOyhQmHHEp
 cwItWX4O3vYqmcDyfUtnsGdJn12y2x8dzmSHtoSkCaymPyuh2IQAGpOlJxIWxOc=
 =StD5
 -----END PGP SIGNATURE-----
 
 --nmemrqcdn5VTmUEE--