Re: $pipestatus and shell functions

["Jérémie Roquet" <arkanosis@gmail.com>]

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