Convert all `sh` scripts to `bash` scripts

[brson]

We've long stuck to posix shell for our bash scripts with the rationale that posix shell is the most compatible. Sometimes this has been painful. Most recently, IllumOS doesn't have a working posix shell, but it does have bash. Conversely, I have no real-world examples of platforms people are using Rust on that only have sh.

I'm near the breaking point of my sympathy for sh now.

This must be done in-tree, as well as in rustup.sh and rust-installer.

This issue has been assigned to @Daniel-Worrall via this comment.

[brson]

cc @steveklabnik

[brson]

cc @rust-lang/tools

[brson]

The obvious place I can imagine this matter is installing rustc on busybox platforms, perhaps Android based.

[wycats]

For what it's worth, I've been playing with getting rust installed on non-standard platforms like aboriginal Linux and unrooted android recently and I can confirm that this is one of the biggest issues.

That said, the script itself is not perfectly compatible with busybox bash, which would be good to fix :)

[steveklabnik]

I'm fine with this 👍

[alexcrichton]

I was poking around in FreeBSD and OpenBSD recently and it looks like neither have bash installed by default, but both have bash packages (just a point of note)

[brson]

@wycats That sounds like a vote for sticking with sh and fixing busybox compatibility?

[wycats]

@brson I think so yes.

[nodakai]

I wonder if we can do something like /non/standard/path/sh configure.sh so that users can choose whichever installation they prefer.

[raphaelcohn]

Just found this thread and I've got a quick observation on sh on BusyBox (I'm the main developer of shellfire).

There's two variants of sh on BusyBox: an ash (Almquist) derived one, and hush. hush is a bit... weird, but is used by some folks because, IIRC, it works on MMU-less systems, and BusyBox's ash doesn't. In addition, BusyBox's ash has a few small patches to accept a few small bashisms. In practice, apart from useful changes to read for scripts using socat, etc, you shouldn't need to rely on any. It's also worth pointing out that ksh is POSIX compliant in its ksh88 form, but isn't in ksh93 form, and its idea of local is at odds with all other shells... it's a completely different feature.

I, and a number of others in the devops space are moving off bash because of its code smells, bug history and brittleness. There have been just too many problems over the years. And it's not commonly installed on non-Linux setups, etc.

I'd strongly suggest writing scripts and testing with pdksh. If they work with that, they'll work with mksh, dash, bash (running as sh, which is actually uncommon now, as it's often weird), ksh88, OpenBSD's variants, etc. I don't have much availability at the moment (legal shenanigans) but I'm happy to try to help out over email with script issues if you can get me access to a system. Shell script debugging is ...

[Mark-Simulacrum]

@brson Do we want to go with the pdksh approach suggested above? That seems to be the best option based on discussion above.

[Mark-Simulacrum]

Nominating for infra team so we can come to a decision on this.