Groovy hepcat Chris Elvidge was jivin' in alt.os.linux on Fri, 5 May
2023 01:25 am. It's a cool scene! Dig it.

> On 04/05/2023 16:15, RonB wrote:
>> On 2023-05-03, Carlos E.R. <robin_listas@es.invalid> wrote:
>>> On 2023-05-03 12:06, R.Wieser wrote:
>>>> Dan,
>>>>
>>>>> What do you mean "preload" ?
>>>>
>>>> executing the script
>>>>
>>>> . ./loadit
>>>
>>> This is not "executing". This is "sourcing (script) loadit".
>>
>> Just curious. What's the difference? I have scripts that load

Sourcing the script executes its commands in the current shell.
Running the script opens a new shell as a child process of the current
shell.

>> For example this script changes the directory, calls another script
>> (lst) to list files, waits till I enter file name, runs Emacs in full
>> height and adds the .fountain extension and then exits the terminal.
>>
>> #!/bin/bash
>> cd ~/Documents/scripts
>> lst lfount
>> read -p 'file: ' uservar
>> em $uservar &
>> exit
>>
>> If I just run it, it doesn't exit the terminal, but if I source it,
>> it does. I know it works, but I don't know why. Or maybe I do —
>> waiting for me to exit Emacs before exiting the terminal?
>
> Remove the `exit` line?

No; he wants to exit the shell at the end of the script. The answer is
to leave the exit command there and simply source the script, as he is
doing.
He probably doesn't need the shebang line, though.

--

----- Dig the NEW and IMPROVED news sig!! -----

-------------- Shaggy was here! ---------------
Ain't I'm a dawg!!

On 2023-05-06, R.Wieser <address@is.invalid> wrote:
> Ron,
>
>> Thanks for the explanation. Not completely clear on the spawning
>> and environment, but it gives me something to look up.
>
> Yep, it gives you something search for. But as you might get a /lot/ thrown
> at you when you google for either of those words I'm going to make it a bit
> easier for you :
>
> Spawning - starting a new process, mostly by loading and executing a
> program.
>
> Environment : each process runs in its own bit of memory, and has its own
> storage for data.
>
> Though in this, bash case the "environment" I'm talking about is what you
> see when you execute the command "env" or "printenv". Each of the
> displayed lines contains an "environment variable name", followed by an "="
> and than its data.
>
> To uzse them on the commandline or in a (bash) script those words need to be
> prefixed with a "$". Like
>
> echo $USER
>
> or
>
> echo $HOME
>
> You can also make your own, like this :
>
> set myvar=I am $USER
> echo $myvar
>
>
> The "problem" is that when you put those above two lines in a bash script
> and execute it. It displays the correct output, but you won't find the
> "myvar" environment variable back when you afterwards type "env" on the
> commandline - even though you can see the name and its contents when you add
> that "env" command to the script itself.
>
> Why ?
>
> Because of what I mentioned above : when you start a (bash) script the
> normal way a new bash process gets started (with its own copy of its parents
> environment variables!), which than executes the script. After the script
> ends the started bash process also ends, and its copy of the environment
> variables gets thrown away.
>
> IOW, any changes you make to its environment disappear.
>
>
> And thats where "sourcing" comes in : when you "source" a script there is no
> new bash process started, but the script runs in the bash process you typed
> the "source {scriptname}" command in.
>
> And that means that when you than run script with the above two lines
> "sourced" the environment variable does /not/ disappear.
>
> You can do more with "sourcing", but the above is pretty-much it in a
> nutshell.
>
> Hope that helps.

I think I've got it. In my case the answer is, just use source.

--
"Evil preaches tolerance until it is dominant, then it tries to silence good."
-- Archbishop Charles J. Chaput

On 2023-05-08, Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> wrote:
> Groovy hepcat Chris Elvidge was jivin' in alt.os.linux on Fri, 5 May
> 2023 01:25 am. It's a cool scene! Dig it.
>
>> On 04/05/2023 16:15, RonB wrote:
>>> On 2023-05-03, Carlos E.R. <robin_listas@es.invalid> wrote:
>>>> On 2023-05-03 12:06, R.Wieser wrote:
>>>>> Dan,
>>>>>
>>>>>> What do you mean "preload" ?
>>>>>
>>>>> executing the script
>>>>>
>>>>> . ./loadit
>>>>
>>>> This is not "executing". This is "sourcing (script) loadit".
>>>
>>> Just curious. What's the difference? I have scripts that load
>
> Sourcing the script executes its commands in the current shell.
> Running the script opens a new shell as a child process of the current
> shell.

Thanks. So "& exit" just exits out of the child process when executed, but
out of the terminal when using source. I'll just keep using source.

>>> For example this script changes the directory, calls another script
>>> (lst) to list files, waits till I enter file name, runs Emacs in full
>>> height and adds the .fountain extension and then exits the terminal.
>>>
>>> #!/bin/bash
>>> cd ~/Documents/scripts
>>> lst lfount
>>> read -p 'file: ' uservar
>>> em $uservar &
>>> exit
>>>
>>> If I just run it, it doesn't exit the terminal, but if I source it,
>>> it does. I know it works, but I don't know why. Or maybe I do —
>>> waiting for me to exit Emacs before exiting the terminal?
>>
>> Remove the `exit` line?
>
> No; he wants to exit the shell at the end of the script. The answer is
> to leave the exit command there and simply source the script, as he is
> doing.
> He probably doesn't need the shebang line, though.

You're right about removing the shebang line (tested it). But when I take it
out I lose my "code" highlighting. So I'll leave that in also.

Again, thanks. And thanks to everyone for being patient with a slow student.

--
"Evil preaches tolerance until it is dominant, then it tries to silence good."
-- Archbishop Charles J. Chaput