Hi, [email protected] writes:
> Maxim Cournoyer <[email protected]> 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
