unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: elaexuotee@wilsonb.com
Cc: 40641@debbugs.gnu.org,
	"pelzflorian \(Florian Pelz\)" <pelzflorian@pelzflorian.de>
Subject: bug#40641: Building from git breaks when /bin/sh isn't bash
Date: Thu, 21 Jul 2022 11:29:13 -0400	[thread overview]
Message-ID: <8735euqyba.fsf@gmail.com> (raw)
In-Reply-To: <3NB75IRB8776E.2JKL61N4Y2UUG@wilsonb.com> (elaexuotee@wilsonb.com's message of "Tue, 19 Jul 2022 13:14:03 +0900")

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	other threads:[~2022-07-21 15:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15  9:06 bug#40641: Building from git breaks when /bin/sh isn't bash elaexuotee--- via Bug reports for GNU Guix
2020-04-15 12:21 ` pelzflorian (Florian Pelz)
2020-04-17 14:57   ` elaexuotee--- via Bug reports for GNU Guix
2022-06-10  0:34     ` Maxim Cournoyer
2022-06-13 14:40       ` pelzflorian (Florian Pelz)
2022-06-14 16:09         ` Maxim Cournoyer
2022-06-21  0:20           ` elaexuotee--- via Bug reports for GNU Guix
2022-06-21  9:02             ` pelzflorian (Florian Pelz)
2022-07-04 11:22               ` elaexuotee--- via Bug reports for GNU Guix
     [not found]               ` <62c2cd89.1c69fb81.7ad72.92c8SMTPIN_ADDED_BROKEN@mx.google.com>
2022-07-07 21:52                 ` Maxim Cournoyer
2022-07-08  8:53                   ` pelzflorian (Florian Pelz)
2022-07-08  8:58                     ` pelzflorian (Florian Pelz)
2022-07-08  9:51                     ` elaexuotee--- via Bug reports for GNU Guix
2022-07-10  4:56                     ` Maxim Cournoyer
2022-07-10 10:13                       ` elaexuotee--- via Bug reports for GNU Guix
     [not found]                       ` <62caa649.1c69fb81.5b288.1112SMTPIN_ADDED_BROKEN@mx.google.com>
2022-07-10 19:55                         ` Maxim Cournoyer
2022-07-11 13:48                           ` Maxim Cournoyer
2022-07-19  4:14                             ` elaexuotee--- via Bug reports for GNU Guix
2022-07-21 15:29                               ` Maxim Cournoyer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8735euqyba.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=40641@debbugs.gnu.org \
    --cc=elaexuotee@wilsonb.com \
    --cc=pelzflorian@pelzflorian.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).