Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#42134 - [bash] Change the symlink /bin/sh from bash to dash

Attached to Project: Arch Linux
Opened by Savyasachee Jha (genghizkhan91) - Friday, 26 September 2014, 19:08 GMT
Last edited by Allan McRae (Allan) - Saturday, 27 September 2014, 00:43 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No


Please changing the /bin/sh symlink from /usr/bin/bash to /usr/bin/dash

First of all, this is not because of the recent shell shock bug. The bug itself, however, facilitated the discussion on the mailing list (first mail of said discussion:

This discussion hinged on many points. The first was that a script running with /bin/sh should request a POSIX-compliant shell. GNU bash can be run in a POSIX compliant mode, yes, however, said mode is not fully POSIX compliant. Debian's dash and posh are both said to be better compliant with the POSIX standard. (Source: Anecdotal evidence and Google searches.)

Another reason was that there are many programs which issue a system() call, which, as is given in its man page, invokes /bin/sh, and as such should be given a shell which is closely POSIX compliant, as that is what has been asked for.

Third, as Ubuntu has noted (, dash is faster than bash and is a better choice performance-wise in non-interactive scripts seeking POSIX-compliant shells. It also happens to be smaller. Dash, after being installed, is a mere 128 KiB, whereas bash is 6.6 mb. It has been noted that dash built-ins work faster than bash ones. This link ( is not exactly a scientific study of minute differences between the shells, but does seem to give some credibility to this claim. Anecdotal evidence gathered via Google searches also points to this.

Fourth, it encourages code-correctness as scripts With a #!/bin/sh header would require to be POSIX compliant if they are to run, as is required on *buntu and Debian. Dash has been the default in Ubuntu since 6.06, I believe, and in Debian since Squeeze, hence the required lack of bashisms should not break stuff unduly.

Fifth, it does not interfere with scripts which are written with bash in mind.

Sixth, dash is already in core. While posh is supposed to be a bit more POSIX.2 compliant than dash, dash is actively used by both Ubuntu and Debian as the default non-interactive shell.

Lastly, while it seems like a pompous argument after the above, using dash for /bin/sh seems to be closer to the Arch Way than using bash. In particular, the simplicity and code-correctness points seem to resonate here.

Thank you
This task depends upon

Closed by  Allan McRae (Allan)
Saturday, 27 September 2014, 00:43 GMT
Reason for closing:  Won't implement
Additional comments about closing:  No overreactions here...
Comment by Dave Reisner (falconindy) - Friday, 26 September 2014, 19:32 GMT
dash lacks a privileged mode of operation, meaning that it retains root privileges when called from a setuid program. Pretty much every other shell in existence drops privileges when invoked with EUID != UID, because it's the safe and sane thing to do in order to protect users from poorly written setuid programs. dash was offered a patch to add this and ignored it[1] -- simply because they care about POSIX correctness over everything else.

> Third, as Ubuntu has noted (
This page doesn't really give much useful information. Startup time of bash on my machine is 3 times the startup time of dash... but that said, bash consumes 3 milliseconds rather than 1 millisecond. I'm not going to lose sleep or productivity over this.

Comment by Savyasachee Jha (genghizkhan91) - Friday, 26 September 2014, 20:46 GMT
Not being a coder, I'd like to ask, wouldn't it be easier to disable setuid on shell scripts? Or do you mean that once a shell script has requested elevated permissions (say for example calling sudo rm <file-path>), then dash doesn't drop permissions back down to normal once a second command has been called?
Comment by Allan McRae (Allan) - Friday, 26 September 2014, 21:34 GMT
Change the symlink yourself and put bin/sh in NoExtract in pacman.conf. Anything requiring bash that does not have /bin/bash is a bug.
Comment by Dave Reisner (falconindy) - Friday, 26 September 2014, 22:00 GMT
> Not being a coder, I'd like to ask, wouldn't it be easier to disable setuid on shell scripts?
The kernel only honors setuid bits on ELF binaries -- it's meaningless on scripts. This is about setuid binaries which shell out without dropping privileges (usually by either calling system() or popen()).
Comment by I Said Socks (socks) - Friday, 26 September 2014, 22:01 GMT
@Savyasachee, thank you for taking time and putting this fine report together.

Sigh... security is hard. My gut reaction is ENV sucks. :(
I'm surprised that dash doesn't choose to do the "safe and sane thing", given Debian's tradition of applying heavily "hardening & misc" patches to upstream code.

At least we are given a reason now; that's progress.
For anyone who still wants to switch /bin/sh to dash or something else, the dash page in Arch wiki gives clear instructions.
Comment by Pablo Lezaeta (Jristz) - Friday, 26 September 2014, 23:43 GMT
Is not part of Arch have code correctness, so why call /bin/sh a POSIX shell and use bashisms that arent part of the standard?
Even if bash keep bein the simlink, I think that is better encourage uptream and developers use the correct shell for the correct functions, no sh for bashisms.

So I vote for the "fix Anything requiring bash that does not have /bin/bash is a bug" reporting upstream and (only if need) fixing here.
I'm careless (for now) for the symlink thing.
Comment by Allan McRae (Allan) - Saturday, 27 September 2014, 00:43 GMT
Nothing in Arch uses /bin/sh and requires bashisms.