Date: Mon, 15 Aug 2005 01:09:00 +0100 From: Brian Somers <brian@Awfulhak.org> To: Bob Willcox <bob@immure.com> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, Colin Percival <cperciva@FreeBSD.org> Subject: Re: cvs commit: src/usr.sbin/portsnap/portsnap portsnap.sh Message-ID: <20050815010900.6f7e0424@dev.lan.Awfulhak.org> In-Reply-To: <20050814020635.GA19321@luke.immure.com> References: <200508132128.j7DLShWb080387@repoman.freebsd.org> <42FE6A67.6000208@freebsd.org> <20050814020635.GA19321@luke.immure.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 13 Aug 2005 21:06:35 -0500 Bob Willcox <bob@immure.com> wrote:
> 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.
No. ksh93, aka the original ksh, is documented to execute the last
command in a pipeline inline. Other shells don't. This is great for
doing things like ``echo $line | read a b c'', and also avoids the
unexpected return/exit not returning or exiting problems that Colin
has seen.
However, traditional Bourne shell scripts have to just handle this sort
of weirdness with constructs like
get input | while read line
do
important command || exit 1
other important command || exit 1
done || exit 1
AFAIK POSIX doesn't explicitly say what's right here, but not having
the POSIX spec handy, treat that with a pinch of salt!!
--
Brian Somers <brian@Awfulhak.org>
Don't _EVER_ lose your sense of humour ! <brian@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050815010900.6f7e0424>