Re: Shell scripts requiring bash

[Thomas Schwinge <thomas at codesourcery dot com>]

Hi!

On Mon, 19 Mar 2012 21:11:06 +0100, I wrote:
> There are several occasions during glibc build (well, most notably during
> testing) where it is assumed that /bin/sh is bash.  If it is not, this
> can be worked around by passing SHELL=/bin/bash on the make command lines
> (it is not enough to pass it once when configuring, as with other GNU
> toolchain packages).
> 
> The issue is: even though the shell scripts contain #!/bin/bash as their
> hashbang, they're still invoked with $(SHELL) [...] from the Makefiles.
> On the other hand, there already is some bash detection magic in
> configure.in.
> 
> What's the way forward?  Should we use something like $(BASH) [...] for
> invoking these scripts?  Should $(SHELL) be set to /bin/bash (instead of
> /bin/sh) if that's available?  Should the scripts be directly invoked
> From the Makefiles (not through $(SHELL); a few need to get Git
> executable attributes), then the hashbang would do the right thing?

Now, as we figured out, there are two occasions where test invocations
fail because Bash arrays are being used, but it might not actually be
Bash that is executing the script:

>     -/bin/sh -e run-conformtest.sh /home/thomas/tmp/source/glibc/glibc.build/conform/ /usr/bin/perl 'gcc -U_FORTIFY_SOURCE -fno-stack-protector' \
>     +/bin/bash -e run-conformtest.sh /home/thomas/tmp/source/glibc/glibc.build/conform/ /usr/bin/perl 'gcc -U_FORTIFY_SOURCE -fno-stack-protector' \
>               '-I../include -I/home/thomas/tmp/source/glibc/glibc.build -I../sysdeps/x86_64/elf -I../nptl/sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/wordsize-64 -I../nptl/sysdeps/unix/sys
>     -run-conformtest.sh: 8: Syntax error: "(" unexpected
>     -make[2]: [/home/thomas/tmp/source/glibc/glibc.build/conform/run-conformtest.out] Error 2 (ignored)
>     +ISO...
>     +ISO99...
>     +[...]
>     +make[2]: [/home/thomas/tmp/source/glibc/glibc.build/conform/run-conformtest.out] Error 1 (ignored)
> 
> run-conformtest.sh uses arrays, and thus fails if invoked with dash.

>     -/bin/sh -e ../sysdeps/x86_64/tst-xmmymm.sh /home/thomas/tmp/source/glibc/glibc.build/elf/ > /home/thomas/tmp/source/glibc/glibc.build/elf/tst-xmmymm.out
>     -../sysdeps/x86_64/tst-xmmymm.sh: 18: declare: not found
>     -make[2]: *** [/home/thomas/tmp/source/glibc/glibc.build/elf/tst-xmmymm.out] Error 127
>     +/bin/bash -e ../sysdeps/x86_64/tst-xmmymm.sh /home/thomas/tmp/source/glibc/glibc.build/elf/ > /home/thomas/tmp/source/glibc/glibc.build/elf/tst-xmmymm.out
> 
> Again arrays.

David, are you (as well as the maintainers) actively interested in
turning these into POSIX shell scripting compliant code?  Otherwise,
which of my three ``should'' proposals from above would the maintainers
prefer?

I would continue to use arrays (and thus change some infrastructure to
invoke Bash instead of /bin/sh); I agree with Joseph's position (OK to
use Bash internally) quoted here:

On Mon, 19 Mar 2012 20:25:33 +0000, "Joseph S. Myers" <joseph@codesourcery.com> wrote:
> On Mon, 19 Mar 2012, David Miller wrote:
> 
> > All of our scripts in the libc tree should be POSIX shell scripts and
> > therefore there is no reason to require BASH explicitly anywhere.
> 
> I'd tend to agree with that for scripts that get installed - it would be 
> good for them to work on systems without bash - but for the build and test 
> process I think it's reasonable to use bash (just like various other GNU 
> tools are needed).


GrÃÃe,
 Thomas

Attachment: pgp00000.pgp
Description: PGP signature