Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question
    
On my system (Debian Testing) sh is a link to dash –  parkydr May 1 '13 at 16:02
    
Are you sure about that? sh should point to dash on Debian stable which is why you get its manpage. –  terdon May 1 '13 at 16:02
    
This is indeed discussed on bugs.debian.org/cgi-bin/bugreport.cgi?bug=662159 –  mpy May 1 '13 at 16:03
    
@parkydr It looks like I must have changed the symlink at some point in the long history of running this computer. –  ACK_stoverflow May 1 '13 at 17:17
    
@mpy Good find, but I've never run a distupgrade on this machine. Looks like I must have changed the symlink myself. –  ACK_stoverflow May 1 '13 at 17:18

2 Answers 2

up vote 7 down vote accepted

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.

share|improve this answer
    
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 May 1 '13 at 17:09
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 May 1 '13 at 17:24
    
Ok. Like you said, the default login shell is bash, so I guess the state of my adduser.conf makes sense. –  ACK_stoverflow May 1 '13 at 18:05

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.

share|improve this answer
1  
What does the TL;DR refer to? You didn't read your own post? –  terdon May 1 '13 at 16:33
    
@terdon it's a fairly standard internetism, equivalent in this context to 'to cut a long story short' or 'short version:' –  evilsoup May 1 '13 at 16:42
    
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 initrds, 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 May 1 '13 at 17:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.