Date: Sat, 13 Aug 2005 14:47:19 -0700 From: Colin Percival <cperciva@freebsd.org> To: Colin Percival <cperciva@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.sbin/portsnap/portsnap portsnap.sh Message-ID: <42FE6A67.6000208@freebsd.org> In-Reply-To: <200508132128.j7DLShWb080387@repoman.freebsd.org> References: <200508132128.j7DLShWb080387@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Colin Percival
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42FE6A67.6000208>