Dash As The Default Shell For Fedora?

[RahulSundaram]

I read the thread and it looks like it's mainly Rahul Sundaram pushing for it to be considered, a couple people agreeing, and several very vocal opponents. And it would seem to me that the discussion is going against it.

Let's take this one step at a time

https://fedorahosted.org/fesco/ticket/1352

If FESCo doesn't agree to that, I will consider it a failed proposal.

[gens]

i... read the first some comments in the relevant thread
mostly people stating relevant details or their opinion

then i seen Lennart's comments... i'l stop reading anything fedora related from now
in short:

"The shell is API. Currently, if people write shell (#!/bin/sh) scripts
on Fedora, they can be sure that the same language is available on all
Fedora installations. If you suddenly make /bin/sh something that
might be different on all systems, you pretty much break API there."

for anyone reading that does not know "sh" was the original bourne shell
and #!/path/binary literally tells the kernel what to execute

"If you change /bin/sh to dash, then you'll have to map two shell
binaries into memory (since the login shell is going to stay on bash),
hence the resource usage grows."

yes, by all the 100kB that is not shared by dash (it's ~500kB in bash)

"You also increase the attack surface, since there'll be two shells running."

if they are bout running or not does not matter since they are not open to the network
more so that only one of those running shells will be by a user
it only matters if an attacker can RUN that shell; and if he has your ssh password, he can choose

"Also, many of the bashisms are
actually pretty useful, hence you replace a more powerful language by
a crappier one. You create an entirely new problem for our users, by
making them *think* whether they actually mean /bin/sh or
/bin/bash. You confuse users by disallowing certain expressions in
scripts that work fine if you type them on the interactive shell."

more powerful, no
well a bit more convenient in rare occasions, but also uselessly more complex in others
making users think if /bin/sh is /bin/bash ? what the..
/bin/bash is bash /bin/sh is a shell (ideally it would be ash, as a real sh)

had to say this...
coffee made me read it, i'l tell it to find something else for our next session



on the other hand Ralf Corsepius knows what hes talking about
he has a beer from me when he comes to Croatia

[gens]

in short
i'm rooting for you, Rahul

tell em that most linux users nowadays don't use a shell anyway (ba dum thish)

[roytam1]

I read the thread and it looks like it's mainly Rahul Sundaram pushing for it to be considered, a couple people agreeing, and several very vocal opponents. And it would seem to me that the discussion is going against it.

That's a pity, because it means that the rest of the world can expect to see more broken shell scripts from RH/Fedora users.

I also see that /usr/bin/bash is being mentioned.
This only exists on systems with the /usr merge and possibly some of the BSDs.
/bin/bash is the canonical path on most Linux systems.

Anyhow, regarding compatability:
dash is an old port/fork of the BSD Almquist shell, which is given to unusual behavior; many of its decisions go contrary to most other shells.
It frequently does not have readily useable line editing, what it has is sometimes broken, and it hasn't even kept up with ash.

I would not recommend using a shell where you cannot reliably get line editing, since it's very useful to test shell code while you're writing a script.

Busybox ash is more compatible, has working line editing, may be more POSIX conformant, and will run scripts faster (if you can use Busybox applets).
The ksh variants are much closer to bash; for example, {} expansion works there, and the newer variants support shell arrays.

(Side note: ksh93 got a number of little details right that everyone else got wrong; for an example, take

echo blah |read VAR; echo $VAR

Unfortunately, ksh clones like mksh also got this wrong.)

Locally, checkbashisms is commonly misleading, out of date, or flat-out wrong. For example,
kill -[number] and kill -[SIGNAME] is specifically required in POSIX 2004 (what LSB is based off of); [[ for test is allowed in POSIX and works in any non-ancient shell (newer than Solaris /bin/sh); echo -n works in dash and everywhere else, despite POSIX; support for export VAR=blah is encouraged in POSIX, though not yet mandatory, and it works on all Linux shells.
echo -e, let, and shell arrays are the main ones to notice.

I really can't get what you mean in your code block:

$ bash -c 'echo $BASH_VERSION;echo blah |read VAR; echo x $VAR x'
4.2.37(1)-release
x x

does it suppose to work?

[mirabilos]

(Side note: ksh93 got a number of little details right that everyone else got wrong; for an example, take

echo blah |read VAR; echo $VAR

Unfortunately, ksh clones like mksh also got this wrong.)

This (the ksh behaviour) is actually explicitly permitted by POSIX.

Disclaimer: mksh developer here.

[mirabilos]

I was also considering mksh which is the most used linux shell (1 billion Android devices) which got a pretty impressive set of features for being so light weight. I went for dash because /bin/sh should just adhere to the common standards and since it is non-interactive I should not have to bother about features. Considering making it statically linked against musl ....

You may want to care about bugs, though.

Granted, the segfaults I had with ash in MirBSD earlier are fixed, but dash still uses strcpy() all over the place, and its shell implementation brings tears to my eyes sometimes. Try the IFS-subst-4-1 and IFS-subst-5 testcases from mksh/check.t on dash some day?

Linking mksh statically for /bin/sh is a very good choice. Best to avoid glibc (and its clone ?Clibc, which, while smaller, has even worse code quality), but mksh works just as well with musl (decent Linux libc) as with recent klibc and (Debian-patched) dietlibc.

[mirabilos]

but dash is smallest and less features _might_ mean less attack surfaces...

True. Careful code review *did* find one environment parsing issue specific to mksh. But I found it myself, and it was low-impact enough to not even warrant a CVE.

mksh *did* however get an independent security review by Geremy Condra from Google (for Android) who, like many others who reviewed (without security focus) mksh, was impressed with the quality.

[uid313]

Why don't they make GNU Bash more modular so that it can have compile-time options of features to build.
So then you build two versions of Bash, one for interactive use and one for non-interactive use.

CONFIG_COMMAND_HISTORY = false;
CONFIG_AUTOCOMPLETION = false;
CONFIG_LINE_EDITING = false;