Closed
Description
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.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
brson commentedon Jan 20, 2016
cc @steveklabnik
brson commentedon Jan 20, 2016
cc @rust-lang/tools
brson commentedon Jan 20, 2016
The obvious place I can imagine this matter is installing rustc on busybox platforms, perhaps Android based.
wycats commentedon Jan 20, 2016
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 commentedon Jan 20, 2016
I'm fine with this 👍
alexcrichton commentedon Jan 20, 2016
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 commentedon Jan 20, 2016
@wycats That sounds like a vote for sticking with
sh
and fixing busybox compatibility?wycats commentedon Jan 20, 2016
@brson I think so yes.
nodakai commentedon Jan 23, 2016
I wonder if we can do something like
/non/standard/path/sh configure.sh
so that users can choose whichever installation they prefer.raphaelcohn commentedon May 8, 2016
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: anash
(Almquist) derived one, andhush
.hush
is a bit... weird, but is used by some folks because, IIRC, it works on MMU-less systems, and BusyBox'sash
doesn't. In addition, BusyBox'sash
has a few small patches to accept a few small bashisms. In practice, apart from useful changes toread
for scripts usingsocat
, etc, you shouldn't need to rely on any. It's also worth pointing out thatksh
is POSIX compliant in itsksh88
form, but isn't inksh93
form, and its idea oflocal
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 withmksh
,dash
,bash
(running assh
, 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 commentedon May 4, 2017
@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 commentedon Jun 22, 2017
Nominating for infra team so we can come to a decision on this.
19 remaining items