bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#40641: Building from git breaks when /bin/sh isn't bash


From: Maxim Cournoyer
Subject: bug#40641: Building from git breaks when /bin/sh isn't bash
Date: Thu, 21 Jul 2022 11:29:13 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (gnu/linux)

Hi,

elaexuotee@wilsonb.com writes:

> Maxim Cournoyer <maxim.cournoyer@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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]