Skip site navigation (1)Skip section navigation (2)
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>