[clue] env variables

[marcus hall]

On Mon, Jun 24, 2013 at 05:03:03PM -0600, Quentin Hartman wrote:
> Just a note that removing the #! statement at the top of the file is
> usually a bad idea. That doesn't directly start a new shell, that tells the
> system (not sure if it's bash itself, or if it's a kernel thing) which
> interpreter to use for the script. You can get weird results if you leave
> that out and make the script executable.
> 
> It does though create a new subshell as was mentioned, which always happens
> with script execution (having nothing to do with #!), which is why those
> env_vars don't show up in the parent shell. In order to get them to show up
> in the parent shell, you have to source them from the parent shell:

Normally, when the kernel is told to execute a file, it looks at the first
two bytes to determine the "magic number" of the file.  This determines
how the kernel loads the file into memory (ie, a.out file, ELF file, etc.)
At some point (I believe it was in the BSD kernels first), UNIX systems got
'#!' as a magic number that called a loader that interprets the first line
(after the '#!') as the interpreter for the file and executes that instead
of directly running the file.  This allows binary programs to run shell
scripts (or perl scripts, makefiles, etc.) directly with an exec() system
call.

The shell had traditionally tried to exec() a file first, and if that failed,
it would interpret the file as a shell script.  If the file contains a '#!',
then the exec() will succeed.  If the file does not contain a '#!', then the
exec() will fail and the shell should try to interpret the file itself
instead.

marcus hall
marcus at tuells.org