Re: $pipestatus and shell functions

[Peter Stephenson <Peter.Stephenson@csr.com>]

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