LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (http://www.linuxquestions.org/questions/programming-9/)
-   -   Difference between /bin/bash & /bin/sh (http://www.linuxquestions.org/questions/programming-9/difference-between-bin-bash-and-bin-sh-693231/)

paragkalra 12-27-2008 04:59 AM

Difference between /bin/bash & /bin/sh
 
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.
Quote:

parag@station3:~$ ls -l /bin/bash ; ls -l /bin/sh
-rwxr-xr-x 1 root root 725136 2008-05-13 00:18 /bin/bash
lrwxrwxrwx 1 root root 4 2008-12-03 21:42 /bin/sh -> dash
parag@station3:~$

acid_kewpie 12-27-2008 05:05 AM

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

pixellany 12-27-2008 06:08 AM

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.

unihiekka 12-27-2008 10:54 AM

Quote:

Originally Posted by pixellany (Post 3388380)
On this system (Arch), "sh" is a link to "bash". "dash" is there also.

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.

Telemachos 12-27-2008 11:11 AM

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...)

paragkalra 12-27-2008 11:30 AM

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"

gnashley 12-27-2008 01:15 PM

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.

paragkalra 12-28-2008 02:03 AM

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
Quote:

if 1==1:
print "Equal"
else:
print "No"
I can execute it using:
#python /tmp/sha_python
Quote:

Equal
The interesting thing to note that is if I add a sha-bang header to it. i.e.

#cat /tmp/sha_bang_python
Quote:

#!/usr/bin/python
if 1==1:
print "Equal"
else:
print "No"
and if I invoke it using a wrong interpreter say "perl" still the script would work:
#perl /tmp/sha_bang_python
Quote:

Equal

jiml8 12-28-2008 08:20 AM

Quote:

Originally Posted by gnashley (Post 3388693)
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.

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.

dhanyaelizabeth 01-02-2009 02:05 AM

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

Amerefelie 01-02-2009 05:04 AM

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.

taylor_venable 01-02-2009 06:10 AM

Quote:

Originally Posted by jiml8 (Post 3389360)
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.

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.


All times are GMT -5. The time now is 01:25 AM.