Functionality differences between Bash and sh
Hi All,
Need some explanation on Functionality differences between Bash and sh(better be with examples) Thanks |
BASH, csh, zsh, DASH, etc are all different shells. sh is a symlink to your preferred shell. Have a look ay /bin (in my case):
Code:
ls -l /bin Code:
#! /bin/sh However, if you have a shell script that starts: Code:
#! /bin/bash Code:
#! /bin/csh Hope it starts you off. |
A little excerpt from the Bash manual page:
Code:
If bash is invoked with the name sh, it tries to mimic the startup |
Quote:
if we execute a script which begins with /bin/sh in a bash shell what will be the effect? |
Quote:
|
Quote:
|
This is not entirely germane to this post but I have a post here:
http://www.linuxquestions.org/questi...1/#post4871241 (which I'm inclined to think might have been better on the 'Linux-General' forum). It's a sort of "I understand that I can do this & this but I know that doesn't work - why not?" question. I have only ever used bash. Might, I wonder, some other shell give different results. ming |
The shebang line merely tells the shell which interpreter to use to run the script. So even from BASH:
Code:
#! /bin/csh Similarly: Code:
#! /bin/sh And even: Code:
#! /usr/bin/perl Note also that you can completely leave out the shebang line. When you do this, you can run the script with: Code:
sh myscript Code:
bash myscript Note also that if you leave out the shebang line, you do not need to set the executable bit on the script. |
@towheedm - Thanks for that. I'l play around with it a bit.
|
On most Linux systems /bin/sh is symlinked to either bash or dash, but that doesn't matter. When you run a script as sh, then it will be parsed according to POSIX-defined specifications (with a few legacy bourne-compatible modifications also thrown in), no matter what the actual shell doing the parsing is.
(The POSIX standard defines everything necessary for a minimally compatible unix-like operating system, and one of its parts is a basic shell that supports certain commands and syntax. So every POSIX OS provides some form of /bin/sh, even if the actual shell is bash or ksh, or whatever.) What this means for any particular script depends on what POSIX says, and what the actual shell is. If the code being parsed is explicitly defined by POSIX, then it will be treated as such. syntax or options that are incompatible with POSIX will be rejected with errors. If the code in question is undefined by POSIX, that usually means that it's left up to the individual shell implementation to decide what to do. In practice what this means is that if the shell doing the parsing understands the syntax, then it will usually continue to work. So most bash constructs will continue to work if the reading shell is bash, or possibly ksh. For example, if you try to use an array (an undefined feature) in your sh script, and the parser is bash or ksh, then it will continue to work, at least according to that shell's understanding. But if the parser is dash, it will not, because dash does not support arrays at all. So it's very important, if true portability is required, that you stick with the POSIX syntax; only that is guaranteed to always run*. The dash shell in particular is one that follows POSIX very carefully, and does not have many extensions, if any. so if you want to know if your script will run as sh, try using #!/bin/dash as your shebang. This page has a good rundown of bash syntax constructs and their POSIX equivalents: http://mywiki.wooledge.org/Bashism *Of course even then you still have to deal with differences between platforms and the commands they have available. But that's a different question. |
Quote:
|
All times are GMT -5. The time now is 10:48 PM. |