3
On Debian squeeze. Running ps -p $$
shows bash
is my current shell, ls -l $(which sh)
shows sh
is a symlink to bash
. So why, when I run man sh
, do I get the man page for dash
? Is this just a bug in Debian?
3
On Debian squeeze. Running ps -p $$
shows bash
is my current shell, ls -l $(which sh)
shows sh
is a symlink to bash
. So why, when I run man sh
, do I get the man page for dash
? Is this just a bug in Debian?
8
The system default shell is different than your user shell. On my system, dash
is system default, but I use bash
when I log in:
anthony@Zia:~$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Mar 1 2012 /bin/sh -> dash
So, a shell script with #!/bin/sh
up top runs with dash.
It sounds like your system somehow has half and half, where the /bin/sh symlink and manpage symlink got out of sync. The manpage symlink on my system is:
anthony@Zia:~$ ls -l /usr/share/man/man1/sh.1.gz
lrwxrwxrwx 1 root root 9 Mar 1 2012 /usr/share/man/man1/sh.1.gz -> dash.1.gz
If you've manually changed the /bin/sh one, you'll have to change that one, too. Possible there is a bug around handling those symlinks, too; mpy points out Bug #662159.
Each user has a setting for which shell to invoke on login. That's a per-user setting, stored in /etc/passwd
, so the system-wide manpage can't reflect it. Each user can change his/her shell setting by running chsh
(and, of course, root can change other users' shell settings).
There is also a SHELL
environment variable, which gets set on login, but can be changed. Generally, it overrides the shell field in /etc/passwd
for when, e.g., xterm
needs to start a shell.
Well, I've never run a distupgrade
, so mpy's bug isn't the issue. I have modified my system pretty heavily over the years, so I guess it's possible I manually changed the symlink.
I just tested creating a new user via Gnome (System->Admin->Users), and that user also had /bin/bash set as its shell by default.
No matter, you guys are telling me that my system is nonstandard. Thanks for the info. – ACK_stoverflow – 2013-05-01T17:09:36.250
1@ACK_stoverflow the default user shell for new users is set in /etc/adduser.conf
, at least if you're using that tool to add users (which GNOME probably is...). – derobert – 2013-05-01T17:24:29.600
Ok. Like you said, the default login shell is bash
, so I guess the state of my adduser.conf
makes sense. – ACK_stoverflow – 2013-05-01T18:05:42.467
1
TL;DR /bin/sh used to be a completely different shell in other UNIXes (Solaris) but was Bash in Linux, but Debian decided to have a custom /bin/sh shell for various reasons (mostly code size).
The original shell was Bourne shell. POSIX rules require that a Bourne compatible shell is installed as /bin/sh. This is what you get when you ask for man sh
.
Bourne shell actually was pretty raw. It didn't have a lot of interactive features that people wanted in a command interpreter. it had no history mechanism, no aliases, etc. So there were some additions made. First this came in tcsh, then in Korn shell, then in Bash.
When you're making a Linux distro, you need to follow POSIX rules for /bin/sh. They saw "hey we have Bash, which is shell forward compatible from Bourne shell". Why don't we just strip the few features from it and install it as /bin/sh? Most distros did this.
But there are some problems with this. Bash has a lot of features (readline bindings, programmable completion, dictionary arrays, etc...) and is actually pretty big on memory, and has a few library dependencies. These are not particularly good when you're in "my system is borked" mode. You care more about getting your system up than worrying about if I have a fully programmable prompt at that point.
So, the Debian folks went back to the future, and have a specialized, stripped Bourne shell as /bin/sh. It's smaller, fewer dependencies, and in theory can be more reliable at startup. The downside is that there may be startup scripts that kind of depended on /bin/sh really being Bash underneath, and may use those features. But those are scripts that were coded out of spec, and should be fixed.
The original shell was the Thompson shell, not Bourne. The sh
language standardized by POSIX was in fact mostly Korn shell compatible, not Bourne. And the Debian Almquist shell is not, as its name gives away, a stripped down Bourne shell. It is the Almquist shell, with a small number of things added by the Debian people because they were too much work elsewhere for them to do without. – JdeBP – 2018-05-15T19:45:24.793
1What does the TL;DR refer to? You didn't read your own post? – terdon – 2013-05-01T16:33:36.090
@terdon it's a fairly standard internetism, equivalent in this context to 'to cut a long story short' or 'short version:' – evilsoup – 2013-05-01T16:42:47.673
Actually, the chief reason behind promoting dash
to be /bin/sh
was raw speed of startup and script execution, not reliability. When reliability (and keeping the dependencies at a minimum) is a requirement, which is true for initrd
s, busybox
is typically used as a shell, which is a different beast completely (links against a special libc
or is even built statically, implements many programs of coreutils
and other packages by itself via hardlinking them to itself etc). – kostix – 2013-05-01T17:35:59.463
On my system (Debian Testing) sh is a link to dash – parkydr – 2013-05-01T16:02:05.630
Are you sure about that?
– terdon – 2013-05-01T16:02:46.883sh
should point todash
on Debian stable which is why you get its manpage.This is indeed discussed on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662159
– mpy – 2013-05-01T16:03:01.160@parkydr It looks like I must have changed the symlink at some point in the long history of running this computer. – ACK_stoverflow – 2013-05-01T17:17:09.883
@mpy Good find, but I've never run a
distupgrade
on this machine. Looks like I must have changed the symlink myself. – ACK_stoverflow – 2013-05-01T17:18:08.013