Re: Odd bugs when no job control support

2016-08-03 Thread Chet Ramey
On 7/31/16 1:46 PM, Olivier Brunel wrote:
> Hi,
> 
> (Please Cc me as I'm not subscribed to the list; Thank you.)
> 
> So I was cross-compiling bash (version 4.3.42(1)-release,
> x86_64-pc-linux-musl) and came accross some "odd" bugs. It's not quite
> easy to describe how they occur, so let me use a script to help:
> 
> ---8<---
> #!/usr/bin/bash
> 
> foo() {
> while read; do
> echo ERROR
> done < <(true)
> }
> 
> echo before
> foo

Thanks for the report.  This was reported and fixed back in January, 2016:

http://lists.gnu.org/archive/html/bug-bash/2016-01/msg00063.html

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/



Odd bugs when no job control support

2016-07-31 Thread Olivier Brunel
Hi,

(Please Cc me as I'm not subscribed to the list; Thank you.)

So I was cross-compiling bash (version 4.3.42(1)-release,
x86_64-pc-linux-musl) and came accross some "odd" bugs. It's not quite
easy to describe how they occur, so let me use a script to help:

---8<---
#!/usr/bin/bash

foo() {
while read; do
echo ERROR
done < <(true)
}

echo before
foo

shopt -u execfail

echo after
foo
--->8---

Expected output would be:

before
after

Simple as that. However, I would get the following:

before
after
ERROR

But to be clear: this happened simply because shopt was used to set, or
unset, an option. Regardless of which option or even whether it was
already (un)set or not. The simple fact to call shopt to (un)set is what
triggered things, causing code in loops as shown to be executed when
it shouldn't be.

After investigations, this in fact turned out to be linked to me
cross-compiling, and specifically the fact that, then, some things are
disabled by configure since checking for them isn't possible; Namely
named pipes & job control -- The later being apparently the root of this
bug.

In my tries, I also noticed at some point that a test from run-inverts
would fail, namely:

$ ! (false); echo $?
1

However, doing `export bash_cv_job_control_missing=present` before
running configure allowed to have job control built in, and also made
both issues go away.

As mentionned earlier, the bash cross-compiled was linked against musl,
I just tried "cross-compiling" against glibc (as in, feeding configure a
different triplet for --host, e.g. x86_64-pc-linux-musl, but it was a
native gcc) and got similar results, only the script behaves a little
differently:

before
ERROR
after
ERROR

Seems it doesn't work as expected even before/without calling shopt
then. However:

$ ! (false); echo $?
1

just the same.

Then, I tried (regular) compiling (against glibc) but passing
--disable-job-control to configure, and got:

before
ERROR
after
ERROR

So the bug occurs then as well, making things even easier to
reproduce. :) Things are a little different with inverts, but still not
quite right:

$ ! (false); echo $?
0
$ (false); echo $?
0
$ false; echo $?
1

Lastly I tried the same thing but linking musl instead (via musl-gcc),
and the script gets me:

before
after
ERROR

So again with musl, a call to shopt is needed to trigger the issue, no
idea why. As for the inverts, same results as when linked to glibc:

$ ! (false); echo $?
0
$ (false); echo $?
0
$ false; echo $?
1

I believe that's all I know about this; Hopefully this can be helpful.
Regards,