What am I wanting to see after make check on glibc.

Bill's LFS Login lfsbill at nospam.dot
Sat Nov 8 08:55:29 PST 2003

On Sat, 8 Nov 2003, [iso-8859-1] Jörg W Mittag wrote:

> [Intentional Fullquote]
> Pascal J.Bourguignon wrote:
> > Kevin P. Fleming writes:
> >> Pascal J.Bourguignon wrote:
> >>><snip>

> Just for the sake of completeness, this is what POS^H^H^HSUSv3 has to
> say about it:
> <URL:http://opengroup.org/onlinepubs/007904975/utilities/xcu_chap02.html#tag_02_09_03>:
> | Lists
> |
> | An AND-OR list is a sequence of one or more pipelines
> | separated by the operators "&&" and "||" .
> [...]
> | The operators "&&" and "||" shall have equal precedence and shall
> | be evaluated with left associativity. For example, both of the
> | following commands write solely bar to standard output:
> |
> | false && echo foo || echo bar
> | true || echo foo && echo bar
> Actually, looking at SUSv2
> <URL:http://opengroup.org/onlinepubs/007908799/xcu/chap2.html#tag_001_009_003_003>
> and <URL:http://rhols66.adsl.netsonic.fi/era/unix/shell.html>, which is a
> HTMLification of Steve R. Bourne's original tutorial from way back in the 70s, it
> seems that this should work in just about *any* Bourne/POSIX/SUS compliant UNIX
> shell.

And it *does*. The problem is that the end user is often not (initially)
aware that the "specs" do *not* say what should happen with the return
code and that leaves the door open for the actual implementation: the
alternative pipeline *may* be unexpectedly executed because the second
conditional operator test the result of the last executed pipeline,
which may have been the command executed as a result of a "true" on the
first conditional operator.

That's the only problem: what humans *expect* vs. what may *really*

> jwm

Bill Maltby
Fix line above & use it to mail me direct.

More information about the lfs-support mailing list