Ubuntu – /bin/sh, /bin/bash and /bin/dash all broken, how can I install them again

bashdash-shelldpkg

Removed all /bin/sh, /bin/bash and /bin/dash. I cannot install them because dpkg and apt-get need a shell to install and there is no shell available. I'm still logged in and my Ubuntu is still running. Is there a way to recover from this situation. By the way, I don't have a Live CD right now.

Best Answer

As you currently have a working system:

Download the packages. Normally I'd suggest running apt-get download bash dash but if you have a browser, you can fish them manually from http://packages.ubuntu.com/ Just make sure you get the version for your distribution release and architecture.
Extract the files you need and put them in the right place. You might need to Alt+F2 to run pkexec nautilus to get root access to write.

/bin/sh is actually a symlink to /bin/dash. I'm not sure how this is managed (it's a "diversion", but I'm not sure by which package) so you might need to manually create the symlink. Again from Alt+F2:
```
pkexec ln -s /bin/dash /bin/sh
```

But I'd also download a LiveCD now while you're at it and get that burnt onto a USB stick. If you've forgotten anything you're going to need that when you reboot.

Related Solutions

Ubuntu – How to the script determine whether it’s being run by bash or dash

You can make the fact that $BASH_VERSION is blank in dash work for you:

if [ "$BASH_VERSION" = '' ]; then
    echo "This is dash."
else
    echo "This is bash."
fi

Bash vs Dash – Concrete Speed Figures and Benchmarks

This test is not representative for the boot process, but you can simply try out yourself by making a little test script, I called it shspeed:

$ cat shspeed
for a in `seq 10000`; do ( :; ); done

This simply forks 10000 subshells one after another. Now run it with bash and with dash and time it:

$ time dash shspeed
dash shspeed  0,70s user 0,33s system 107% cpu 0,965 total

$ time bash shspeed
bash shspeed  1,59s user 0,76s system 108% cpu 2,180 total

So, it's a lot faster on my hardware, which is a ~1 year old Dell XPS 13 9365. You can imagine that it makes a bigger difference on low end hardware. Also, this test is only about a for loop and spawning a sub shell. Perhaps for some tests the results will be even more significant.

Of course, you can ignore that and say you do not care about how fast it is to spawn 10000 sub shells. Well, some seem to care :)

For your particular boot process it probably would not make any noticeable difference. I don't see a problem if you use /bin/bash as /bin/sh and measure the difference with a stop watch.

Please check these links from @wjandrea for detailed explanation of the matter: https://wiki.ubuntu.com/DashAsBinSh, What is the point of sh being linked to dash?

Shell speed in times of systemd

After your modified your question it sounds more like you are not so much interested in which shell is faster, but more why we still stick to making the boot process half a second faster (or so), especially now that we are not using shell scripts anymore to the same extent we did when sysv-init was the standard.

Since I am not involved in the politics of Ubuntu I will try to give an answer as it appears to me:

If you can make something half a second faster by simply using a symlink to another shell, it's worth it.
Having the default shell do nothing but what POSIX requires the default shell to do makes sense in order to keep things portable. Imagine one distribution uses a bash feature in an init script that another distribution does not have (yet).
(d)ash was also added to be able to fix bashisms in standard scripts, and also to avoid them in the future. /bin/sh is an agreed on standard, something big big infrastructures are depending on. Nothing I would like to replace with something having a much larger code base with unneeded features.
Using less CPU cycles and memory is always worth it. Even systemd units often are running shell scripts in the background.

All this is likely irrelevant for the average user, but indirectly what they get is an overall more stable distribution.

Why not bash?

This is more of an opinion: Personally I would never choose to script in dash. It offers very basic constructs only. For a bigger piece of software I would rather choose bash or zsh (or something not shell at all). Which features I would want to use perhaps: advanced parameter expansions, shell arithmetics, arrays, maybe some more.

This should not happen in scripts primarily used for starting up daemons or installing software. Those should use a minimum set of instructions and keep scripts readable and simple. But it would likely happen if all the goodness of bash would be available to them.

/bin/sh should be mainly for running external programs in a reasonably convenient environment, not for complex software systems.

Summary

/bin/sh, as implemented by dash, brings a POSIX compatible fast and stable scripting language, that works well as the standard and default interpreter for system shell scripts. These properties will never be sacrificed in favour of convenience features.

From a programmer's point of view it fulfills the mantra of "do one thing and do it well".

It is not primarily an optimisation, but separation of duties.

It is already there, so it is no additional effort to keep it.

Looking at this with end-user-hat on poses the question: what kind of end-user? A desktop user couldn't care less, but they would still benefit from a more stable (and perhaps tiny bit faster) distribution. A package maintainer would care a lot, and those benefit from a reliable system interpreter with a small, well-defined and well-tested set of features. A programmer shouldn't care, as they likely do not develop in /bin/sh.

PS: the bash binary is almost 10 times the size of the dash binary!