According to Wikipedia /bin/sh means Bourne shell . Is that Right?
Yes.
Quote:
Question2.
So, in Solaris 10, RHEL Version5, version 6, AIX version 6, 7 , if i forget to add shebang to a script , will the script be executed using Bourne shell ?
Yes. Anything calling itself UNIX will have a Bourne shell available by default. Even on systems where c-shell is popular, Bourne is still available, because too many system things depend on it to exclude it. You could get more than you asked for -- BASH or DASH on Linux for instance -- but you will at least get generic Bourne features.
On Solaris you might get an extremely old pre-POSIX Bourne, to the point it doesn't understand $(this) syntax, only `backticks`, so if you forget the shebang, you might not get everything you need.
Quote:
Question3.
Regarding CarloM's post on sourcing . /path/to/script.sh
I have used sourcing only to set environmental variables in the current shell. Can sourcing be used to execute shell scripts as well?
Yes, entire shell scripts can be run. You could make an environment script that sets different variables for different users, for instance. Or an entire script of any purpose.
Note that the effect of exit is to make the shell quit. If it's running in a separate shell, it makes that shell quit. If it's running in your shell, it makes your shell quit. If you want a sourced script to exit without killing your terminal, use return instead.
Quote:
Question4.
I have noticed that some people execute shell scripts by putting sh at the beginning like
Code:
sh /path/to/myscript.sh
I always execute shell scripts without the sh at the beginning.
Code:
/path/to/script.sh
Which is recommended ?
Like said above, sh scriptname ignores the shebang, forcing it to use sh no matter what. What if it actually needs a full-fledged BASH or KSH shell, or something weirder like csh? sh scriptname wouldn't work. So I consider it best to let the shebang decide which interpreter to use.
This is a point of debate, however. There's arguments both ways.
Last edited by Corona688; 08-31-2012 at 01:46 PM..
...You did not clearly and unambiguously state the exact commands that you used to create your script and run it. Please do so.
...
Here is a screen dump when testing different cases - version info as first command (only some info hidden and added comments as "# ..."):
Code:
# new fresh login...
[user@server ~]$ uname -a
FreeBSD xxx.yyy.zz 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 UTC 2007 ...
[user@server ~]$ cd test/
[user@server ~/test]$ cat tfs
[[ 1 == 1 ]] && echo yes || echo no
[user@server ~/scripts]$ ls -l tfs
-rwxr--r-- 1 user user 36 Aug 31 20:34 tfs
# run the script (the folder is not in PATH):
[user@server ~/test]$ ./tfs
yes
# testing forcing sh:
[user@server ~/test]$ sh tfs
[[: not found
no
# testing forcing bash:
[user@server ~/test]$ bash tfs
yes
# enter sh:
[user@server ~/test]$ sh
[2 user@server /usr/home/user/test]$ ./tfs
[[: not found
no
# enter bash:
[2 user@server /usr/home/user/test]$ bash
[3 user@server ~/test]$ ./tfs
yes
[3 user@server ~/test]$ exit
exit
[2 user@server /usr/home/user/test]$ exit
[user@server ~/test]$ env
# some taken away...
DL_IMP=../data/import/contacts/
SHELL=/usr/local/bin/bash
TERM=xterm
SSH_TTY=/dev/ttyp1
USER=user
ENV=/home/user/.shrc
PAGER=more
FTP_PASSIVE_MODE=YES
EDITOR=vi
HOME=/home/user
LOGNAME=user
_=/usr/bin/env
...
[user@server ~/test]$
Quote:
Originally Posted by alister
...If the system call fails with ENOEXEC, that means that an executable file was found but its format is not recognized. This happens if the file is a foreign binary or if it's a shell script without a shebang. execvpe(3) then reattempts to execve a bourne shell with the unrecognized file as its first argument.
Can it be that it's only when the file is a foreign binary that it falls back to _PATH_BSHELL?
eneric Bourne doesn't have to support [[ ]]. Some do, some don't, so if you don't know what shell you're going to get, limit yourself to [ ] .
You should also have a blank line as the first line of the script, in case your first line accidentally ends up being a command. [ is a command for instance.
So, really, I reccomend having a shebang even if you don't plan on using it, just in case someone else does, and to at least document which variety of shell is preferred for it.
Code:
#!/bin/sh
[ 1 -eq 1 ] && echo yes || echo no
Last edited by Corona688; 08-31-2012 at 04:32 PM..
# enter sh:
[user@server ~/test]$ sh
[2 user@server /usr/home/user/test]$ ./tfs
[[: not found
no
# enter bash:
[2 user@server /usr/home/user/test]$ bash
[3 user@server ~/test]$ ./tfs
yes
... <snip> ....
Can it be that it's only when the file is a foreign binary that it falls back to _PATH_BSHELL?
No. The code in the libc functions (and the kernel syscall they invoke) does not make that distinction.
I can replicate your observation on an old debian system using bash 3.1.17. Bash must not be using any of those libc functions. If it were, /bin/sh would have been called. Bash is sidestepping them, either by invoking execve(2) directly or by using an exec*(3) variant which does not have any of the /bin/sh fallback semantics, so that it can use itself to interpret executable files that aren't recognized by the kernel.
Like Corona688, I too think it's best to use the shebang. At the very least, it serves as documentation of the author's intentions. At the very most, it's a weak guarantee that the script will be interpreted by a compatible interpreter. Just because it's there, does not mean that it will be used. If the script is sourced by an interpreter, or fed on standard input, or passed as a command line argument -- in other words, when a shell is reading the script -- the shebang is treated as a comment and ignored. The shebang is only relevant when the kernel itself, in execve(2), is reading the script.
It is recommended to specify the full path when executing a script and have a correct Shebang line in the script. This is unambiguous and quick.
It is not recommended to invoke the Shell directly with a parameter of the script name (with or without the full path).
If there is no Shebang line and the Shell has not been invoked directly all unix/Linux systems that I have encountered invoke /bin/sh by default.
On many (by by no means all) modern systems /bin/sh is the Posix Shell (or /bin/bash on Linux).
Your system appears to be behaving like Sun/Oracle Solaris (or many unix O/S derived from Berkeley unix) where /bin/sh is the Bourne Shell. On RedHat Linux /bin/sh is linked to /bin/bash .
Just to verify whether there is a lnk on your system, what is the output from:
Code:
ls -lisad /bin/sh
ls -lisad /bin/bash
Quote:
According to Wikipedia /bin/sh means Bourne shell . Is that Right?
No, It is wrong. If you agree that it is wrong, just change it.
On modern HP-UX for example /usr/old/bin/sh is the Bourne Shell and /bin/sh is the Posix Shell.
This is definitely a shell-implementation detail that boils down to whether the shell is using the libc functions that fallback to /bin/sh or not.
I installed a few shells on someone's Ubuntu 12.04 LTS box and ran a few tests. The results do not in anyway conclusively prove anything about the implementation details except that some of these shells are definitely not using execlp/execvp/execvpe. sh is a symlink to dash. The sh/dash error message is used to determine whether it is used by the other shells.
Code:
$ cat tests/shebang.sh
[[ " " ]]
echo $?
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Aug 27 15:15 /bin/sh -> dash
# dash 0.5.7-2ubuntu2 (baseline)
$ sh ./tests/shebang.sh
./tests/shebang.sh: 1: ./tests/shebang.sh: [[: not found
127
$ dash ./tests/shebang.sh
./tests/shebang.sh: 1: ./tests/shebang.sh: [[: not found
127
$ bash --version | head -n1
GNU bash, version 4.2.24(1)-release (x86_64-pc-linux-gnu)
$ bash
$ ./tests/shebang.sh
0
$ bash ./tests/shebang.sh
0
$ ksh --version
version sh (AT&T Research) 93u 2011-02-08
$ ksh
$ ./tests/shebang.sh
0
$ ksh ./tests/shebang.sh
0
$ pdksh
$ print $KSH_VERSION
@(#)PD KSH v5.2.14 99/07/13.2
$ ./tests/shebang.sh
./tests/shebang.sh: 1: ./tests/shebang.sh: [[: not found
127
$ pdksh ./tests/shebang.sh
./tests/shebang.sh[1]: syntax error: `" "' missing expression operator
$ zsh --version
zsh 4.3.17 (x86_64-unknown-linux-gnu)
$ zsh
$ ./tests/shebang.sh
./tests/shebang.sh: 1: ./tests/shebang.sh: [[: not found
127
$ zsh ./tests/shebang.sh
./tests/shebang.sh:1: parse error near `]]'
In summary, bash and ksh use themselves when the kernel does not recognize the executable, while pdksh and zsh use /bin/sh (most likely through libc functions).
Hi ,
I know about the shebang line in shell scripting. Just want to know whether is there any difference in execution of the program by keeping and not keeping the shebang line. Because without shebang line also the script is working. correct me if am wrong. Any help on this will be helpful (5 Replies)
Hi,
I have a trivial question to ask, I am seeing in some shell scripts the '-' (hyphen) character following the first line of shell script (i.e) the shebang notation as follows:
#!/bin/sh -
#! /bin/bash -
what does the hyphen signify? What will happen if it is not given explicitly? (2 Replies)
Hi,
I always thought that #!/usr/bin/ksh means that the script would be executed in korn shell i.e. when we'll execute the script with this line as the very first line then the shell spawns a korn shell (in this case as we are using #!/usr/bin/ksh ) and the script gets executed.
But I am... (7 Replies)
*** EDIT: I found something close to my solution under an IIS 7 Module Handle.*****
(Non-Homework question, simply an ease of use one)
Odd question here and maybe its my newness to cgi/Perl, but is it possible to have 2 shebang lines?
I write an test a ton of my homework code on my windows... (1 Reply)
Can any one tell me how to replace a shebang line of a file using sed?
Eg: If a file contains the following shebang line
#!C:/InstantRails/ruby/bin/ruby
I would like to replace it with
#!/usr/local/bin/ruby
The shebang line of the file can be obtained from the command
cat... (3 Replies)
Do we need to include the exclamatory mark in the shebang line??:confused:
What if we dont include it??:eek:
Actually what shebang line implies when we run a script??
shebang line--> #!/bin/ksh :p (6 Replies)
Hi,
I am currently writing BASH shell scripts. I am using BASH on a Powerbook G4 running Leopard. Could somebody please explain the difference between
#!/bin/bash and #!/bin/sh?
I have been using the latter (#!/bin/sh), and things have been working fine. But is that the correct one to use... (9 Replies)
08-31-2012
If you want a sourced script to exit without killing your terminal, use return instead.