[RFC] Replace Bash with basic Bourne compatible shell for portability.

[apotheon]

The /bin/bash path in the build system is not fully portable. Some OSes (e.g. BSD Unix systems and some Linux-based systems) do not have Bash installed by default, and when installed from packages (or even on some systems with Bash installed by default) the Bash executable path is not in /bin. For increased portability and reduced dependency requirements, while remaining compatible with Linux distributions that use Bash as the default system shell, I recommend using a basic Bourne compatible shell with the path /bin/sh instead.

The following is a quote about this matter from issue #97 :

Changing from /bin/bash to /bin/sh would require some minor syntactic
changes that I noticed, but would then remain consistent with Bash, because
the Bash-specific syntax for those changes I stumbled onto are redundant with
syntax that also works with Bourne shell. I do not know off the top of my
head whether there are actual features particular to Bash that would also
need to be worked around.

Keeping Bash while porting Chaos to new OSes (e.g. BSD Unix systems) may require programmatically determining the Bash executable path rather than hardcoding it and adding dependency handling for Bash installation in build configuration steps.

[apotheon]

It looks like the majority of scripts can be fixed by simply (case-sensitively) grepping for "bash" in the project and replacing each instances with "sh" using your favorite editor. I don't recommend using sed to do it; some files contain instances of the string "bash" that may be important.

There are some cases where just changing the shebang line of a script is not sufficient. It may be worthwhile for now to leave everything under tests alone, if they are not necessary for just users building Chaos on systems without Bash installed by default, but I'll address some things I noticed there anyway.

Of course, many scripts under tests are not very testable here, due to the lack of ability to build Chaos in the first place.

I don't know of a shell-portable way to declare arrays -- not even just for Bourne-syntax shells like Z Shell, Korne Shell, and Bash (let alone C Shell syntax). I noticed that both tests/official_spells.sh and tests/rosetta/install.sh contain Bash-style arrays that do not, in fact, even need to exist. I recommend deleting the array assignment in both and changing the first line of the for loop using the array to something like the following:

for spell in math string array json

Doing that reveals some other compatbility issues arising from tests/official_spells.sh. I suspect they are related to the use of gmake instead of bsdmake.

In tests/interpreter.sh, the use of GNU/Bash getopt errors out with /bin/sh because of long options (e.g. --long; on my system, it complains that -l, -n, and -g are not available options) and would need to be replaced. I usually just roll my own command line options for shellscripts; your mileage may vary.

There are other files I have not checked that contain the string "bash". It might be worthwhile to go through the list of results produced by:

$ grep -R bash * | sort | uniq

I hope this helps.

[naltun]

I am also a fan of POSIX sh.

@mertyildiran I think this is a good idea as, already put, it allows for greater portability.

Will most of our users have Bash installed? Probably. But some won't, and this will inherently exclude BSD users.

Also, there is a new rise of Unix-like operating systems that provide sh-compatible shells (RedoxOS and SerenityOS come to mind). These systems, although new, will see users in the future (imho).

By tackling this now, we can quash any portability issues and create a greater surface area for attracting new users.

For the last two years I have only been writing POSIX sh, so I can take this task on.