cvs commit: src/usr.sbin/portsnap/portsnap portsnap.sh

[Bob Willcox]

On Sat, Aug 13, 2005 at 02:47:19PM -0700, Colin Percival wrote:
> Colin Percival wrote:
> >   This bug was caused by the astonishing interaction of "return" and
> >   pipelines; in the following code, the "return" does not exit the
> >   function, but instead exits the subshell which was spawned for the last
> >   element of the pipeline; consequently, the output produced is "foo".
> >   
> >   foo() {
> >           echo bar | while read baz; do
> >                   if [ ${baz} = "bar" ]; then
> >                           return 1
> >                   fi
> >           done
> >   
> >           echo foo
> >   }
> 
> For what it's worth, I don't know if the behaviour of our sh(1) is correct
> here.  IEEE 1003.1, 2004 Ed. says
> 
> "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."
> 
> and I don't see any mention of not returning from a function just because we
> happen to be inside a subshell.

I tried this on a some different shells. Turns out that bash & pdksh
behave similar to the FreeBSD shell, but with ksh93 the return exits the
function. So maybe ksh93 is the only one working correctly--or it's the
only one that's broke.

Bob

> 
> Colin Percival
> _______________________________________________
> cvs-all at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/cvs-all
> To unsubscribe, send any mail to "cvs-all-unsubscribe at freebsd.org"

-- 
Bob Willcox                The early bird who catches the worm works for someone
bob at immure.com             who comes in late and owns the worm farm.
Austin, TX                         -- Travis McGee