mjhjmtu

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.

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; on AIX, /proc/$$/object/a.out is a link to the executable).




• 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

Yes it does. By the way it is 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.

In fact, if you take it consequently, the executable noted in the shebang line, is just an executable. It makes sense to use some text interpreter as executable, but it is not necessary. Just for clarification and demonstration, i made a rather useless test:

#!/bin/cat
useless text
more useless text
still more useless text

Named the file test.txt and set the exectuable bit chmod u+x test.txt, then "called" it: ./test.txt. As expected, the contents of the file is output. In this case, cat does not ignore the shebang line. It simply outputs all lines. Any useful interpreter should thus be able to ignore this shebang line. For bash, perl and PHP, it is simply a comment line. So yes, these ignore the shebang line.

The exec system call of the Linux kernel understands shebangs (#!) natively

When you do on bash:

./something

on Linux, this calls the exec system call with the path ./something.

This line of the kernel gets called on the file passed to exec: https://github.com/torvalds/linux/blob/v4.8/fs/binfmt_script.c#L25

if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!'))

This reads the very first bytes of the file, and compares them to #!.

If that is true, then the rest of the line is parsed by the Linux kernel, which makes another exec call with path /usr/bin/env python and the current file as the first argument:

/usr/bin/env python /path/to/script.py

and this works for any scripting language that uses # as a comment character.

And yes, you can make an infinite loop with:

printf '#!/an' | sudo tee /a
sudo chmod +x /a
/a

Bash recognizes the error:

-bash: /a: /a: bad interpreter: Too many levels of symbolic links

#! just happens to be human readable, but that is not required.

If the file started with different bytes, then the exec system call would use a different handler. The other most important built-in handler is for ELF executable files: https://github.com/torvalds/linux/blob/v4.8/fs/binfmt_elf.c#L1305 which checks for bytes 7f 45 4c 46 (which also happen to be human readable for .ELF). This reads the ELF file, puts it into memory correctly, and starts it running. See also: https://stackoverflow.com/questions/8352535/how-does-kernel-get-an-executable-binary-file-running-under-linux/31394861#31394861

Finally, you can add your own shebang handlers with the binfmt_misc mechanism. For example, you can add a custom handler for .jar files. This mechanism even supports handlers by file extension. Another application is to transparently run executables of a different architecture with QEMU.

I don't think POSIX specifies shebangs, however: https://unix.stackexchange.com/a/346214/32558, although it does mention it in rationale sections, and in the form "if executable scripts are supported by the system something may happen".

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.