$pipestatus and shell functions

$pipestatus and shell functions

[Jérémie Roquet]

Hello,

I'm somewhat confused by the behaviour of the $pipestatus variable:

$ true | true ; echo $pipestatus
0 0
$ false | true ; echo $pipestatus
1 0
$ true | false ; echo $pipestatus
0 1
$ false | false ; echo $pipestatus
0 0
$ foo() { true }
$ true | foo ; echo $pipestatus
0 0
$ false | foo ; echo $pipestatus
1 0

So far, everything is fine for me, but then:

$ foo() { false | true }
$ true | foo ; echo $pipestatus
1 0
$ foo() { false | false }
$ true | foo ; echo $pipestatus
1 1
$ foo() { true | true | true }
$ false | foo ; echo $pipestatus
0 0 0

So $pipestatus is defeated by multiple pipelining…

Is this by design? If so, is there some not-so-complicated workaround
to get the exit code of process A in “ A | B ” for any B (ie. even if
B is itself a shell function with a pipe)?

Thanks in advance, best regards,

-- 
Jérémie

Re: $pipestatus and shell functions

[Peter Stephenson]

On Mon, 11 Apr 2011 17:52:24 +0200
Jérémie Roquet <arkanosis@gmail.com> wrote:
> $ foo() { false | true }
> $ true | foo ; echo $pipestatus
> 1 0
> $ foo() { false | false }
> $ true | foo ; echo $pipestatus
> 1 1
> $ foo() { true | true | true }
> $ false | foo ; echo $pipestatus
> 0 0 0
> 
> So $pipestatus is defeated by multiple pipelining…
> 
> Is this by design?

I don't think this particular effect is deliberate.  You're falling foul
of (i) a shell function looks like a job to the shell (ii) it appears
that function is being made the current job, so generates the pipe
status when it exits (the same happens if you use a { ... } expression
there, so that's not a workaround).  However, there's some truly
horrible handling for job control in complicated cases like this (what
is supposed to get signals and what do you return to if you get one?) so
it's quite possible that those two contributing factors are themselves
deliberate.  I'm not entirely convinced, though; it surprises me that
that the notion of the current job changes like that.

> If so, is there some not-so-complicated workaround
> to get the exit code of process A in “ A | B ” for any B (ie. even if
> B is itself a shell function with a pipe)?

Do you need B to be running in the current shell?  If not,

A | ( B )

will work.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: $pipestatus and shell functions

[Peter Stephenson]

On Mon, 11 Apr 2011 17:38:35 +0100
Peter Stephenson <Peter.Stephenson@csr.com> wrote:
> Jérémie Roquet <arkanosis@gmail.com> wrote:
> > $ foo() { false | true }
> > $ true | foo ; echo $pipestatus
> > 1 0
> 
> You're falling
> foul of (i) a shell function looks like a job to the shell (ii) it
> appears that function is being made the current job, so generates the
> pipe status when it exits (the same happens if you use a { ... }
> expression there, so that's not a workaround).  However, there's some
> truly horrible handling for job control in complicated cases like
> this (what is supposed to get signals and what do you return to if
> you get one?) so it's quite possible that those two contributing
> factors are themselves deliberate.  I'm not entirely convinced,
> though; it surprises me that that the notion of the current job
> changes like that.

A little digging suggests it is deliberate.  If you ever have a week to
spare, look at the comment relating to the declaration of list_pipe in
exec.c.  Within the description of the example:

    cat foo | while read a; do grep $a bar; done

you find

   If the user hits ^Z at this point (and jobbing is used), the
   shell is notified that the grep was suspended. The list_pipe flag is
   used to tell the execpline where it was waiting that it was in a pipeline
   with a shell construct at the end (which may also be a shell function or
   several other things). When zsh sees the suspended grep, it forks to let
   the sub-shell execute the rest of the while loop.

So the shell is deliberately treating constructs in the right hand side
of the pipeline as jobs in their own right, and in particular as the
current foreground job, since that's the one where you can do job
control.  This overrides the natural expectation that the pipeline is
the current job and so the one for which $pipestatus would be reported.

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: $pipestatus and shell functions

[Jérémie Roquet]

Hi Peter,

2011/4/11 Peter Stephenson <Peter.Stephenson@csr.com>:
> On Mon, 11 Apr 2011 17:38:35 +0100
> Peter Stephenson <Peter.Stephenson@csr.com> wrote:
>> Jérémie Roquet <arkanosis@gmail.com> wrote:
>> > $ foo() { false | true }
>> > $ true | foo ; echo $pipestatus
>> > 1 0
>>
>> You're falling
>> foul of (i) a shell function looks like a job to the shell (ii) it
>> appears that function is being made the current job, so generates the
>> pipe status when it exits (the same happens if you use a { ... }
>> expression there, so that's not a workaround).  However, there's some
>> truly horrible handling for job control in complicated cases like
>> this (what is supposed to get signals and what do you return to if
>> you get one?) so it's quite possible that those two contributing
>> factors are themselves deliberate.  I'm not entirely convinced,
>> though; it surprises me that that the notion of the current job
>> changes like that.
>
> A little digging suggests it is deliberate.  If you ever have a week to
> spare, look at the comment relating to the declaration of list_pipe in
> exec.c.  Within the description of the example:
>
>    cat foo | while read a; do grep $a bar; done
>
> you find
>
>   If the user hits ^Z at this point (and jobbing is used), the
>   shell is notified that the grep was suspended. The list_pipe flag is
>   used to tell the execpline where it was waiting that it was in a pipeline
>   with a shell construct at the end (which may also be a shell function or
>   several other things). When zsh sees the suspended grep, it forks to let
>   the sub-shell execute the rest of the while loop.
>
> So the shell is deliberately treating constructs in the right hand side
> of the pipeline as jobs in their own right, and in particular as the
> current foreground job, since that's the one where you can do job
> control.  This overrides the natural expectation that the pipeline is
> the current job and so the one for which $pipestatus would be reported.

Makes sense for job control, but that's… counter intuitive for
$pipestatus. I've to think a bit longer about it ;)

Anyway, thanks a lot for your help, the subshell trick does the job.

Best regards,

-- 
Jérémie