I know it's a very silly question but could someone please explain the difference between "/bin/bash" & "/bin/sh"

I was under the impression that both are same but following output on my Ubuntu 8.10 is making me raise my eyebrows.

Well bash is a variant of a unix shell, as is csh, ash, ksh, dash and many others. Dash is a simpler shell than bash, as you can read here. http://en.wikipedia.org/wiki/Debian_Almquist_shell

On this system (Arch), "sh" is a link to "bash". "dash" is there also.

So I assume that "sh" is used as a generic name for whatever shell you want it to link to.

Dash is the faster version of bash, actually. It's not very much faster in my opinion and experience, but it's supposed to be at least.

There are many possible shells a distro or administrator can pick from. Bash is, I believe, the most popular default shell at this point in the Linux world, but it is a reasonably "heavy" shell. It includes tons of features that are helpful for interactive use (when a user is typing into the shell and getting feedback from the shell), but unnecessary when you are running scripts non-interactively. For that reason, many distros (or local systems administrators) will install a "lighter" shell (smaller size & faster because it doesn't have those interactive features) at /bin/sh. Debian's /bin/sh going forward is supposed to be Dash, though I think they are still working on removing all the Bash-dependent features in their system-wide scripts. (Perhaps this is already finished by now, so don't quote me on that.)

On the other hand, some distros figure that Bash is plenty fast, even for non-interactive use, and leave Bash as /bin/sh. They all use /bin/sh as a placeholder name, I think, because historically, that's where many older shell scripts go looking for the default, system-wide shell. (Going back a bit, /bin/sh was generally the Bourne shell, though there were other defaults before that. Bash is the "Bourne-again shell" - another of GNU's cutesy pun names.)

Footnote: no flames, please. When I say that Bash is the most popular, I just mean to state a fact about usage. (That said, I love me some Bash shell...)

Thanks guys...I got my answer...so the conclusion is:

1. If am executing the shell script using absolute or relative path, then interpreter used would be the one mentioned as sha-bang header.
2. And if I am using "sh" to invoke the shell script, interpreter used would be the one linked with "/bin/sh"

About two years ago a few distros started using dash as the default system shell, but it wasn't because of a speed difference. dash is a POSIX compliant shell, so it was a move towards stricter POSIX compliance which prompted the move. It was, and probably still is, a painful move since the change breaks thousands of exiting scripts which use 'bashisms'. Of debian was probably at the forefront of the change, but I think Mandriva also made the change early.
Even bash-3.2 is causing lots of headaches if compiled for newer POSIX standards compliance.

ABck to the question: If you have /bin/sh as a link to bash, then bash will not behave the same when called as /bin/sh as it does when called as /bin/bash. When called as 'sh', it will limit itself to mostly POSIX-compliance plus a limited set of extensions.

A quick way to demonstrate the difference is to create a small script and use double brackets in an 'if' conditional test. If you run the script with bash called explicitly it will work, but if you run it with bash called as 'sh' it will fail. YMMV depending on how your bash was compiled.

Just to add more info, 3rd way to execute a script is directly through the interpreter. For e.g. consider following python script

#cat /tmp/sha_python
I can execute it using:
#python /tmp/sha_python
The interesting thing to note that is if I add a sha-bang header to it. i.e.

#cat /tmp/sha_bang_python
and if I invoke it using a wrong interpreter say "perl" still the script would work:
#perl /tmp/sha_bang_python

My Mandriva workstation uses bash with sh as a symlink to bash. I have dash available with the name /bin/dash.static. Of course, this workstation has been upgraded since Mandrake 7.2 and never reinstalled so YMMV.

I do have a target development system on which I deployed Mandriva 2008.0 just a couple of months ago as a clean install, and that system does not have dash on it at all, and sh is a symlink to bash.

If in fact the distros are making a move to dash for ideological reasons (which an insistence on POSIX compliance certainly is) then that is one of the more stupid things I have ever heard of.

This is a very informative thread. And to think that, till now, I thought the only difference between bash and sh were that they were two shells from different vendors/authors.

Linux Archive

The #! at the head of a script tells your system that this file is a set of commands to be fed to the command interpreter indicated. So it shouldn't matter what interpreter you use to call the script, the interpreter indicated after the #! is what will actually be used evaluate the script.

#!/bin/sh invokes the default shell interpreter and conforms to the POSIX sh standard. This should then allow the script to be portable though you lose interpreter specific features.

see TLDP's Advanced Bash-Scripting Guide and "man magic" for more info.

If the intended effect is to get people to recognize that /bin/sh is not bash, then that is a good thing to me. Since my systems actually have an implementation of the Bourne shell, programs that rely on /bin/sh being bash are just plain annoying since I have to manually correct them. There's really little excuse for such an assumption; if you want to use bash features, put bash in the hash-bang line!

It's not like this has never been this way. Historically, sh was the name of the Bourne shell; on Unixen that are more UNIX than Linux, like the BSD derivatives, /bin/sh is an implementation of the Bourne shell. To confuse bash and sh is to confuse two different languages and sets of features. Sure, one is a superset of the other, but they are still distinct and for portability reasons you should treat them as distinct.

As an analogy think of it this way: you wouldn't write C code as if it were being compiled by a C++ compiler, using mostly C syntax and semantics but sprinkling in a little std::cout when convenient.

Also a "best practices" note for people using the hash-bang line because I don't see it as often as I should: use /usr/bin/env to find the interpreter. Some people don't install their software in the same place as you, so rather than hard-coding #!/usr/bin/python (if you're on OpenBSD for example, it would be /usr/local/bin/python) use #!/usr/bin/env python -- that way the user's PATH gets searched. If the system is POSIX-ly compliant then /usr/bin/env will be there, but for other programs like python or bash (mine is in /usr/local/bin/bash not /bin/bash) you cannot just assume that it will be where you think it is.