[sf-lug] 'source' works but 'shebang' doesn't

[jim]

[ optional idle tho't ]

     Trouble with child programs is that there's
(famously) no way for a child to write to its
parent's envionment.
     There's Inter-Process Communication (IPC)
but I'm unclear about that.
     The only persistent means is to write to the
file system, which ain't bad for testing:

$ ls
somefile
$ . ./myscript.sh  ## both dash and bash have the  .  command
$ ls
somefile    childrec
$

the  . command is the short name for source command,
and is built in to both dash and bash.

myscript.sh is a shell script that does something
or another and has at least an echo statement that
redirects string(s) to the childrec file.

echo "$MYVAR and other info the script gathered" > childrec

or maybe

if [ SOMETEST ]; then
     echo "$MYVAR etc" > childrec
     exit 73
fi

Assuming myscript is called by some other script
that has a trap statement, exit 73 returns the
integer value 73 to the calling program, and that
might trigger the calling program to read the
childrec file. Not IPC, but might be good enough?



On 08/26/2016 09:11 PM, Alex Kleider wrote:
> On 2016-08-26 11:44, Akkana Peck wrote:
>> Alex Kleider writes:
>>> Mystery:
>>>
>>> alex at X301n3:~/Py/Backup/Backup$ cat ./path.sh
>>> #!/bin/bash
>>> # Add current working directory to the PYTHONPATH.
>>> export PYTHONPATH="${PYTHONPATH:+$PYTHONPATH:}$(pwd)"
>> [ ... ]
>>> I don't understand how
>>> source ./path.sh
>>> does the job but
>>> ./path.sh
>>> does not!
>>>
>>> Can anyone explain?
>>
>> It is working -- just not the way you expect.
>>
>> When you run ./path.sh, it looks at the shebang and runs the shell
>> you specify there -- as a subshell of the one you're typing in. That
>> subshell reads the lines of the script and exports PYTHONPATH in
>> that subshell, and when it's done reading the script, it exits,
>> leaving you in your original shell, which still has its original
>> environment.
>>
>> When you source ./path.sh, "source" explicitly tells your current
>> shell to run the commands in the script *in the current shell*.
>> So this time, export modifies your current shell rather than
>> executing a subshell.
>
> Of course!  I should have known that.  Thanks for taking the time to 
> explain.
> It's much appreciated.
>
>>
>> Source also ignores the shebang line, since you've explicitly told
>> it you want your current shell to execute it, not some other
>> program. Even if you have a shebang line that says something like
>> #!/usr/bin/env python, with source your shell will try to execute it
>> as a shell script. Try it! It's especially amusing if your python
>> program starts with import lines: I'll leave the question of what
>> it's doing in that case as a fun exercise for the reader.
>
> Exercise completed- ... and understood:-)
>
> My tentative conclusions:
>
> source myscript # use existing shell to interpret code in file 
> myscript ignoring lines after '#' including '#!'.  Changes to 
> environment will persist in the existing shell.
>
> ./myscript # another shell is spawned to open the file as if it were a 
> command- if it finds a shebang, the appropriate program is 
> commissioned to take over, otherwise, the spawned shell continues to 
> read and execute.  Changes to environment will pertain to the spawned 
> shell only and so will be lost when the script is finished.
>
> As I write the above, another thought comes to mind: in the latter case-
> If the spawned shell finds a shebang referring to bash, does the 
> spawned shell then spawn another instance of bash to run the script?
>
> _______________________________________________
> sf-lug mailing list
> sf-lug at linuxmafia.com
> http://linuxmafia.com/mailman/listinfo/sf-lug
> Information about SF-LUG is at http://www.sf-lug.org/<br>
> http://www.shallowsky.com/blog/
>