Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

This may be a silly question, but I ask it still. If I have declared a shebang

#!/bin/bash 

in the beginning of my_shell_script.sh, so do I always have to invoke this script using bash

[my@comp]$bash my_shell_script.sh

or can I use e.g.

[my@comp]$sh my_shell_script.sh

and my script determines the running shell using the shebang? Is it the same happening with ksh shell? I'm using AIX.

share|improve this question
3  
there is a little confusion on your part: when you do "_some_shell some_script" it starts _some_shell and asks it to interpret some_script. So no, if you do "sh my_shell_script.sh" it won't interpret the shebang, but will interpret the script in sh instead. To use the shebang : chmod +x my_shell_script.sh ; /path/to/my_shell_script.sh # or ./my_shell_script.sh if you happen to be in its directory –  Olivier Dulac Aug 21 '13 at 11:04

3 Answers 3

up vote 31 down vote accepted

The shebang #! is an human readable instance of a magic number consisting of the byte string 0x23 0x21, which is used by the exec() family of functions to determine whether the file to be executed is a script or a binary. When the shebang is present, exec() will run the executable specified after the shebang instead.

Note that this means that if you invoke a script by specifying the interpreter on the command line, as is done in both cases given in the question, exec() will execute the interpreter specified on the command line, it won't even look at the script.

So, as others have noted, if you want exec() to invoke the interpreter specified on the shebang line, the script must have the executable bit set and invoked as ./my_shell_script.sh.

The behaviour is easy to demonstrate with the following script:

#!/bin/ksh
readlink /proc/$$/exe

Explanation:

  • #!/bin/ksh defines ksh to be the interpreter.

  • $$ holds the PID of the current process.

  • /proc/pid/exe is a symlink to the executable of the process (at least on Linux, I'm not familiar with AIX so I don't know the equivalent there).

  • readlink will output the value of the symbolic link.

Example:

Note: I'm demonstrating this on Ubuntu, where the default shell /bin/sh is a symlink to dash i.e. /bin/dash and /bin/ksh is a symlink to /etc/alternatives/ksh, which in turn is a symlink to /bin/pdksh.

$ chmod +x getshell.sh
$ ./getshell.sh 
/bin/pdksh
$ bash getshell.sh 
/bin/bash
$ sh getshell.sh 
/bin/dash
share|improve this answer

Yes it does. By the way itis not a silly question. A reference for my answer is here. Starting a Script With #!

  • It is called a shebang or a "bang" line.

  • It is nothing but the absolute path to the Bash interpreter.

  • It consists of a number sign and an exclamation point character (#!), followed by the full path to the interpreter such as /bin/bash.

    All scripts under Linux execute using the interpreter specified on a first line Almost all bash scripts often begin with #!/bin/bash (assuming that Bash has been installed in /bin) This ensures that Bash will be used to interpret the script, even if it is executed under another shell. The shebang was introduced by Dennis Ritchie between Version 7 Unix and 8 at Bell Laboratories. It was then also added to the BSD line at Berkeley .

Ignoring An Interpreter Line (shebang)

If you do not specify an interpreter line, the default is usually the /bin/sh. But, it is recommended that you set #!/bin/bash line.

share|improve this answer
2  
To elaborate, the kernel only knows how to execute statically linked binaries and where to find interpreter information for others (a special field in the binary, or the shebang line). Typically executing a shell script means following the shebang line to the shell, and then following the DT_INTERP field in the shell binary to the dynamic linker. –  Simon Richter Aug 21 '13 at 6:37
3  
Also note that this isn't limited to shell scripts. All text based script files use this. eg #!/usr/bin/perl #!/usr/local/bin/python #!/usr/local/bin/ruby Another common shebang entry used to support multiple systems is to use env to locate the interpreter you want to use, like #!/usr/bin/env perl #!/usr/bin/env python –  sambler Aug 21 '13 at 7:31
    
@sambler speaking of env, which should be actually prefered? Python and Perl often use env, while on shellscripts, this is often omitted and shebang points to the shell in question. –  polemon Aug 21 '13 at 10:22
    
@polemon less of which is preferred and more on which paths vary. The basic shells are in the same path on all systems. Up to date versions of perl and python can be installed in different locations on different systems so using env allows the same shebang to always work, which is why env is used more with perl and python scripts than shell scripts. –  sambler Aug 22 '13 at 8:23

From what I gathered, whenever a file has an executable bit set and is invoked, the kernel analyzes the file header in order to determine how to proceed (as far as I know, you can add custom handlers for custom file formats via LKMs). If the file appears to be a text file with a #! combination in the beginning, its execution is dispatched to another executable (usually a shell of sorts), a path to which is to be specified directly after the said shebang, in the same line. The kernel then proceeds to execute the shell and pass the file for it to handle.

In short, it doesn't matter which shell you invoke the script with - the kernel will dispatch the execution to the appropriate one either way.

share|improve this answer
2  
There's a marked difference between bash ./myscript.sh and ./myscript.sh. –  Michael Kjörling Aug 21 '13 at 9:35
    
What do you mean by this "marked difference"? –  jrara Aug 21 '13 at 9:59
1  
@jrara See my answer, the statement that "it doesn't matter which shell you invoke the script with" is simply not true. –  Thomas Nyman Aug 21 '13 at 10:33

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.