Return codes and pipelines

Return codes and pipelines

[Rolf Campbell]

/home/rcampbell> (true | true) && echo true || echo false
true
/home/rcampbell> (true | false) && echo true || echo false 
false 
/home/rcampbell> (false | true) && echo true || echo false 
true 
/home/rcampbell> (false | false) && echo true || echo false 
false

The third test above yields different results when run on Linux.  I'm
wondering if this was the desired result or not?  (This is not a new
problem, it's been around for at least a year of releases).  It makes
some makefiles not work as expected, specifically, the GCC manual
describes how to perform auto-dependency analysis like:

gcc ... | sed ...

But, if gcc fails, sed will still work, thus make will not consider it a
failure and will continue.

I know there are many ways to avoid this specific problem, already
implemented one.  Just wanted to let you guys know.


-Rolf Campbell
Software Designer
Tropic Networks

Re: Return codes and pipelines

[Randall R Schulz]

Rolf,

One posting is enough, really.

There is no guaranteed or specified parent child relationship between the 
processes in a pipeline. This means that you cannot predict which process's 
status will be the one returned as that of the pipeline as a whole.

You can force this in your contrived example by adding an exit call.

All of these will print "true:"

(true | true; exit 0) && echo true || echo false
(false | true; exit 0) && echo true || echo false
(true | false; exit 0) && echo true || echo false
(false | false; exit 0) && echo true || echo false


Randall Schulz


At 14:09 2003-01-12, Rolf Campbell wrote:
>/home/rcampbell> (true | true) && echo true || echo false
>true
>/home/rcampbell> (true | false) && echo true || echo false
>false
>/home/rcampbell> (false | true) && echo true || echo false
>true
>/home/rcampbell> (false | false) && echo true || echo false
>false
>
>The third test above yields different results when run on Linux.  I'm
>wondering if this was the desired result or not?  (This is not a new
>problem, it's been around for at least a year of releases).  It makes
>some makefiles not work as expected, specifically, the GCC manual
>describes how to perform auto-dependency analysis like:
>
>gcc ... | sed ...
>
>But, if gcc fails, sed will still work, thus make will not consider it a
>failure and will continue.
>
>I know there are many ways to avoid this specific problem, already
>implemented one.  Just wanted to let you guys know.
>
>
>-Rolf Campbell

Re: Return codes and pipelines

[Jon LaBadie]

On Sun, Jan 12, 2003 at 02:21:45PM -0800, Randall R Schulz wrote:
> Rolf,
> 
> One posting is enough, really.
> 
> There is no guaranteed or specified parent child relationship between the 
> processes in a pipeline. This means that you cannot predict which process's 
> status will be the one returned as that of the pipeline as a whole.
> 


> 
> At 14:09 2003-01-12, Rolf Campbell wrote:
> >/home/rcampbell> (true | true) && echo true || echo false
> >true
> >/home/rcampbell> (true | false) && echo true || echo false
> >false
> >/home/rcampbell> (false | true) && echo true || echo false
> >true
> >/home/rcampbell> (false | false) && echo true || echo false
> >false
> >
> >The third test above yields different results when run on Linux.  I'm
> >wondering if this was the desired result or not?


There is (or had been last I looked at the source) a defined relationship
in the Bourne and Korn shells at least.

The parent forks the last command in a pipeline which then becomes the
parent of the other commands in the pipeline.  Thus the original parent
only sees the last command's exit status.

This scheme was done to implement the following behavior back around
System V.2 in the great Bourne shell "rewrite in C".

From the current Solaris man page for Bourne Shell:

       ...  .  Each  command  is  run  as a separate process; the
     shell waits for the last  command  to  terminate.  The  exit
     status  of a pipeline is the exit status of the last command
     in the pipeline.

The addition of the pipefail option to recent ksh93 versions suggests
this relation-ship scheme has been altered in those shells.  But I
do not think it appropriate to generically say there is no defined
relationship as if it applies to every shell out there.

-- 
Jon H. LaBadie                  jcyg@jgcomp.com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Return codes and pipelines

[Randall R Schulz]

Jon,

Well, Cygwin does not include Bourne shell, it has BASH, ash and zsh, but 
it does appear that the status returned by a parenthesized pipeline under 
BASH is that of the last command in that pipeline.

Strictly speaking, that's not at odds with the first part of what I said, 
which is that the parent - child process relationship between processes in 
a pipeline is not specified.

So this leaves one puzzle: Why is it that Rolf is getting different results 
for this command between Linux and Cygwin?

     (false | true) && echo true || echo false

Rolf, which shells are you using on Linux and Cygwin?

Randall Schulz


At 20:53 2003-01-12, Jon LaBadie wrote:
>On Sun, Jan 12, 2003 at 02:21:45PM -0800, Randall R Schulz wrote:
> > Rolf,
> >
> > One posting is enough, really.
> >
> > There is no guaranteed or specified parent child relationship between the
> > processes in a pipeline. This means that you cannot predict which 
> process's
> > status will be the one returned as that of the pipeline as a whole.
>
>
> > At 14:09 2003-01-12, Rolf Campbell wrote:
> > >/home/rcampbell> (true | true) && echo true || echo false
> > >true
> > >/home/rcampbell> (true | false) && echo true || echo false
> > >false
> > >/home/rcampbell> (false | true) && echo true || echo false
> > >true
> > >/home/rcampbell> (false | false) && echo true || echo false
> > >false
> > >
> > >The third test above yields different results when run on Linux.  I'm
> > >wondering if this was the desired result or not?
>
>
>There is (or had been last I looked at the source) a defined relationship
>in the Bourne and Korn shells at least.
>
>The parent forks the last command in a pipeline which then becomes the
>parent of the other commands in the pipeline.  Thus the original parent
>only sees the last command's exit status.
>
>This scheme was done to implement the following behavior back around
>System V.2 in the great Bourne shell "rewrite in C".
>
> >From the current Solaris man page for Bourne Shell:
>
>        ...  .  Each  command  is  run  as a separate process; the
>      shell waits for the last  command  to  terminate.  The  exit
>      status  of a pipeline is the exit status of the last command
>      in the pipeline.
>
>The addition of the pipefail option to recent ksh93 versions suggests
>this relation-ship scheme has been altered in those shells.  But I
>do not think it appropriate to generically say there is no defined
>relationship as if it applies to every shell out there.
>
>--
>Jon H. LaBadie                  jcyg@jgcomp.com


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Return codes and pipelines

[Jon LaBadie]

On Sun, Jan 12, 2003 at 09:22:55PM -0800, Randall R Schulz wrote:
> Jon,
> 
> Well, Cygwin does not include Bourne shell, it has BASH, ash and zsh, but 
> it does appear that the status returned by a parenthesized pipeline under 
> BASH is that of the last command in that pipeline.


As specified on the bash man page.


> Strictly speaking, that's not at odds with the first part of what I said, 
> which is that the parent - child process relationship between processes in 
> a pipeline is not specified.
> 
> So this leaves one puzzle: Why is it that Rolf is getting different results 
> for this command between Linux and Cygwin?
> 
>     (false | true) && echo true || echo false
> 
> Rolf, which shells are you using on Linux and Cygwin?


And what results?


> At 20:53 2003-01-12, Jon LaBadie wrote:
> >On Sun, Jan 12, 2003 at 02:21:45PM -0800, Randall R Schulz wrote:
> >> Rolf,
> >>
> >> One posting is enough, really.
> >>
> >> There is no guaranteed or specified parent child relationship between the
> >> processes in a pipeline. This means that you cannot predict which 
> >process's
> >> status will be the one returned as that of the pipeline as a whole.
> >
> >
> >> At 14:09 2003-01-12, Rolf Campbell wrote:
> >> >/home/rcampbell> (true | true) && echo true || echo false
> >> >true
> >> >/home/rcampbell> (true | false) && echo true || echo false
> >> >false
> >> >/home/rcampbell> (false | true) && echo true || echo false
> >> >true
> >> >/home/rcampbell> (false | false) && echo true || echo false
> >> >false
> >> >
> >> >The third test above yields different results when run on Linux.  I'm
> >> >wondering if this was the desired result or not?
> >
> >
> >There is (or had been last I looked at the source) a defined relationship
> >in the Bourne and Korn shells at least.
> >
> >The parent forks the last command in a pipeline which then becomes the
> >parent of the other commands in the pipeline.  Thus the original parent
> >only sees the last command's exit status.
> >
> >This scheme was done to implement the following behavior back around
> >System V.2 in the great Bourne shell "rewrite in C".
> >
> >>From the current Solaris man page for Bourne Shell:
> >
> >       ...  .  Each  command  is  run  as a separate process; the
> >     shell waits for the last  command  to  terminate.  The  exit
> >     status  of a pipeline is the exit status of the last command
> >     in the pipeline.
> >
> >The addition of the pipefail option to recent ksh93 versions suggests
> >this relation-ship scheme has been altered in those shells.  But I
> >do not think it appropriate to generically say there is no defined
> >relationship as if it applies to every shell out there.
> >
> >--
> >Jon H. LaBadie                  jcyg@jgcomp.com
> 
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 
> 
>>> End of included message <<<

-- 
Jon H. LaBadie                  jcyg@jgcomp.com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (fax)

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/