GNU bug report logs - #40641
Building from git breaks when /bin/sh isn't bash

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: elaexuotee <at> wilsonb.com
Cc: 40641 <at> debbugs.gnu.org, "pelzflorian \(Florian Pelz\)" <pelzflorian <at> pelzflorian.de>
Subject: bug#40641: Building from git breaks when /bin/sh isn't bash
Date: Thu, 21 Jul 2022 11:29:13 -0400

Hi,

elaexuotee <at> wilsonb.com writes:

> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> wrote:
>> I'll see if these Bashisms can be easily switched to POSIX variants,
>> else I'll experiment with setting the shebang of the test scripts to
>> bash.
>
> Is there any particular reason to go this route?

I can think of at least two:

1. GNU Autotools is designed to work across as many systems as possible,
and produces POSIX-compliant shell scripts such as configure; thus
keeping things in our build system (including the tests authored in
shell scripts) POSIX allows to build and test Guix from source in many
environments, not only in 'guix shell -D guix'.

2. Messing with Autotools-managed variables such as 'SHELL' may end up
causing confusions for those relying on Autotools documented behavior.

> Writing portable scripts is full of all sorts of pitfalls and ill-meaning
> dragons:
>
> - What if SHELL=tcsh?
> - What about incompatible behaviour between bash versions?
> - Do we want to write tests to future-proof fixes for the above?

You actually don't need to care about Bash incompatible behavior when
targetting POSIX shell script.  If the user goes out of their way to use
a non-POSIX shell... well they are on their own.

> In this case, since the build is running inside a guix shell, I don't really
> see any reason to *not* effectively pin the scripts to use the bash available
> in that environment.

That's true for the specific use case where someone tries to build Guix
inside a 'guix shell -D guix' environment, but there are also people
attempting to build Guix using they system provided dependencies and
shell, where the fix wouldn't help.

My previous experiment showed that the Bashisms used seem limited to
perhaps 2 tests; it doesn't seem too difficult to fix them using the
'shellcheck' tool to spot what syntax used is problematic and needs to
be adjusted.

Thanks,

Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.