On 2023-05-03 17:59, R.Wieser wrote:
> Carlos,
>
>>> But the function was named "cleanist()", then he calls "cleanhist".
>>
>> The first is its declaration, the second how its called.
>
> I only just now noticed the typo, that the first one misses a "h". sorry.

So, is it working now?

--
Cheers, Carlos.

Carlos,

>> I only just now noticed the typo, that the first one misses a "h".
>> sorry.
>
> So, is it working now?

No. The typo was in the message, not my script.

Besides, if it would have been in my code I would have had a 'command
doesn't exist' error message - which is unlikely I would have missed it. :-)

In the mean time I've tried to figure out what is happening, and think I
know how, but not why or how to solve it : when I, in the preloaded
function, remove the "history -c" line the "history -s foobar" does indeed
add "foobar" to the history. As such I get the strong feeling that, in the
preloaded function, the clearing of the history is delayed, and only applied
after the "foobar" is added - making it /look like/ that never happened.

By the way, I did add an "echo {something}" to the top and bottom of the
script, just so I could make sure the script runs and does not exit
prematurily. Both messages where shown.

The remaining/new question is : How can I force the preloaded script to
actually execute the "history -c" line before continuing to the next line

Regards,
Rudy Wieser

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 applications
from the command line and then close the terminal. I found the only way I
could do that is use the period (. 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?

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

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 applications
> from the command line and then close the terminal. I found the only way I
> could do that is use the period (. 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?

--
Chris Elvidge
England

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 applications
> from the command line and then close the terminal. I found the only way I
> could do that is use the period (. 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?
>

And you probably don't need the ampersand.

--
Chris Elvidge
England

On 2023-05-04 17: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 applications
> from the command line and then close the terminal. I found the only way I
> could do that is use the period (. source).

Sourcing is used to create variables that are written in the second
script without running it.

>
> 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?

Yes, I think so.

--
Cheers, Carlos.

On 2023-05-04 08:11, R.Wieser wrote:
> Carlos,
>
>>> I only just now noticed the typo, that the first one misses a "h".
>>> sorry.
>>
>> So, is it working now?
>
> No. The typo was in the message, not my script.
>
> Besides, if it would have been in my code I would have had a 'command
> doesn't exist' error message - which is unlikely I would have missed it. :-)

No if you had defined both, each with a different code.

> In the mean time I've tried to figure out what is happening, and think I
> know how, but not why or how to solve it : when I, in the preloaded
> function, remove the "history -c" line the "history -s foobar" does indeed
> add "foobar" to the history. As such I get the strong feeling that, in the
> preloaded function, the clearing of the history is delayed, and only applied
> after the "foobar" is added - making it /look like/ that never happened.
>
> By the way, I did add an "echo {something}" to the top and bottom of the
> script, just so I could make sure the script runs and does not exit
> prematurily. Both messages where shown.
>
> The remaining/new question is : How can I force the preloaded script to
> actually execute the "history -c" line before continuing to the next line

I have never run experiments like that, so I don't know.

--
Cheers, Carlos.

RonB,

>>> executing the script
>>>
>>> . ./loadit
>>
>> This is not "executing". This is "sourcing (script) loadit".
>
> Just curious. What's the difference?

The "difference" is that "sourcing" is a shorthand for executing the script
in the parents environment(meaning : it can alter/create environment
variables of that parent).

IOW, no difference in regard to the execute part, but only in which
environment it uses.

> If I just run it, it doesn't exit the terminal, but if I source it, it
> does.

That is because if you "just run it": bash is spawned (with a copy oif its
parent environment!), and the exit just terminates the spawned bash (and
tthrows its environment away - inclusive any changes you might have made to
it).

On the other hand, if you "source" it (or run it "dotted" - same thing) than
you exit the parent. And as that parent is the top level program in your
terminal that terminal program hasn't anything to run anymore, and thus it
also exits.

Regards,
Rudy Wieser

On 2023-05-04, 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
> applications from the command line and then close the terminal. I
> found the only way I could do that is use the period (. source).

Executing is "run this now".
Sourcing is "read the named file, and insert its contents right here."

Think of it like this -- you've got two files that are related in some
manner (I dunno, a report and a corresponding graph / picture / etc that
needs to be on Page 17 of N)

"Executing" the two files would be printing them both out, and then
manually flipping through the report text until you've gotten to the
right page, then manually inserting the picture (etc.) before stapling
it.

However, "sourcing" the picture into the report would be akin to using
"Insert -> Object ..." and selecting the appropriate *png (etc.). Then
at printing time, the computer simply opens the correct "external file"
and slips it right in for you. (And now you can use the "fancy" printer
that auto-staples each report as it comes out).

>
> 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?

If you run it from an interactive shell (TTY1-N or xterm (etc.)) --

(1) Open Terminal
(2) $ ./RonsScript

Your main shell process will spawn a subshell to run "RonsScript".

The execution flow is:

(0) User Open xterm (etc.)
(1) Shell -- "please tell me what to do"
(2) User -- "run RonsScript"
(3) Shell -- Create child process ("Bash.1")
(4) Shell.1 -- cd ... launch emacs
(5) User -- [interact with emacs], close emacs
(6) Shell.1 -- exit (return control to Bash)
(7) Shell -- "please tell me what to do"

If the shell didn't do this, then basically every script or program
would log us out (if using TTY1-N), or close our chosen terminal
application (xterm (etc.)) when 'exit' was called (such as
exiting with an error code). I don't know about you, but that would
seriously annoy me :)

On the other hand, sourcing it will slap it right into the main shell's
process flow, such that it doesn't believe it needs a subshell. In this
case, the execution flow is:

(1) Shell -- "please tell me what to do"
(2) User -- "add this function defined in RonsScript to your execution
flow"
(3) Shell -- cd ... launch emacs
(4) User -- [interact with emacs], close emacs
(5) Shell -- exit (logout TTY1-N / close xterm)

If you wanted an interactive shell to behave similarly WITHOUT sourcing
the script first, then you'd do things like this:

(1) Open Terminal
(2) $ ./RonsScript ; exit

In this case, the execution flow would be identical to the first one
above, with the additional steps (noting of course that the semicolon
acts as an automatic "okay, now immediately do this" command to the
shell, and preempts the user from seeing the prompt in step 7):

(8) User -- "Please close"
(9) Shell -- exit (logout TTY1-N / close xterm)

Note that in this case, the 'exit' in the script is entirely
superfluous, as the subshell would exit anyway once RonsScript reaches
EOF.

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

Dan,

> Executing is "run this now".
> Sourcing is "read the named file, and insert its contents right here."

You will need to explain that part "insert its contents right here" a bit
more in-depth I'm afraid.

AFAIK /both/ execute the contents of the file. The result depends on whats
in it.

> However, "sourcing" the picture into the report would be akin to using
> "Insert -> Object ..."

No, thats not the same.

Example:

File test1
- - - - - - - - - - - - - - -
echo "hello world"
- - - - - - - - - - - - - - -
either just execute the file ("./test1") or source it ("source test1" or ".
../test1") and the text "hello world" will be displayed.

What you are describing is using a file which contains a function.

File test2
- - - - - - - - - - - - - - -
test3() {
echo "hello world"
} test3
- - - - - - - - - - - - - - -

Execute or source it, and both again will display "hello world"

So, whats the difference ?

The difference is that an "executed" script is run in its own, spawned bash
process - which means that all the changes to its environment are thrown
away when that spawned bash process is terminated when the script ends.

But when the script is "sourced" (or run "dotted", same thing) there is no
bash process spawned, and the script runs in the environment of the current
bash process.

What that means ? It means that the "test3" function isn't discarded, and
can again be called after the script terminates. Just type "test3" <enter>
(the same as the last line in the "test2" script).

It also means that when in the "sourced" test1 script an "env" variable is
changed/created/deleted that that change will "stick".

Having said that, most people just "source" scripts to add a function like
"test3" to the current environment (and won't, directly after declaring it,
run it like I did in the "test2" script).

-- List all current "sourced" scripts:
$ declare -F

-- List the contents of a specific script from
$ declare -f {scriptname}

-- Delete a "sourced" script
$ unset -f {scriptname}

Regards,
Rudy Wieser

On 2023-05-04, Chris Elvidge <chris@mshome.net> wrote:
> 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 applications
>> from the command line and then close the terminal. I found the only way I
>> could do that is use the period (. 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?

Doesn't close the terminal. (With or without the ampersand.)

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

On 2023-05-04, Carlos E.R. <robin_listas@es.invalid> wrote:
> On 2023-05-04 17: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 applications
>> from the command line and then close the terminal. I found the only way I
>> could do that is use the period (. source).
>
> Sourcing is used to create variables that are written in the second
> script without running it.
>
>>
>> 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?
>
> Yes, I think so.

Okay, thanks for the information.

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

On 2023-05-04, R.Wieser <address@is.invalid> wrote:
> RonB,
>
>>>> executing the script
>>>>
>>>> . ./loadit
>>>
>>> This is not "executing". This is "sourcing (script) loadit".
>>
>> Just curious. What's the difference?
>
> The "difference" is that "sourcing" is a shorthand for executing the script
> in the parents environment(meaning : it can alter/create environment
> variables of that parent).
>
> IOW, no difference in regard to the execute part, but only in which
> environment it uses.
>
>> If I just run it, it doesn't exit the terminal, but if I source it, it
>> does.
>
> That is because if you "just run it": bash is spawned (with a copy oif its
> parent environment!), and the exit just terminates the spawned bash (and
> tthrows its environment away - inclusive any changes you might have made to
> it).
>
> On the other hand, if you "source" it (or run it "dotted" - same thing) than
> you exit the parent. And as that parent is the top level program in your
> terminal that terminal program hasn't anything to run anymore, and thus it
> also exits.
>
> Regards,
> Rudy Wieser

Thanks for the explanation. Not completely clear on the spawning and
environment, but it gives me something to look up.

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

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.

Regards,
Rudy Wieser

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

Hello all,

I would like to clean-up my bash history and than preload a certain command.
I would like to preload that script.

The problem is that it only works partially, and I have no idea why.

Assume the scripts name is "cleanhist" and its contents are :

- - - - - - - -
#!/bin/bash
history -c
history -s foobar
- - - - - - - -

running this script "dotted"

.. ./cleanhist

clears the history and adds the "foobar" entry.

However, when I preload that script and than execute it it only empties the
history but does not add the "foobar" entry.

Question : why does the "dotted" script work, but does the preloaded one
only work parially (ignores the "-s" line) ? How do I fix it ?

Regards,
Rudy Wieser

P.s.
I already have a work-around exporting the history to a file, modifying it
and than reloading that file, but would like to use a cleaner solution.

On 2023-05-03, R.Wieser wrote:
> Hello all,
> [...]
> Assume the scripts name is "cleanhist" and its contents are :
>
> - - - - - - - -
> #!/bin/bash
> history -c
> history -s foobar
> - - - - - - - -
>
> running this script "dotted"
>
> . ./cleanhist
>
> clears the history and adds the "foobar" entry.

You're sourcing the script there ...

>
> However, when I preload that script and than execute it it only
> empties the history but does not add the "foobar" entry.

What do you mean "preload" ?

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

Dan,

> What do you mean "preload" ?

executing the script

.. ./loadit

with the contents

- - - - - - - -
cleanist() {
history -c
history -s foobar
} - - - - - - - -

and after that, on the commandline, type

cleanhist

to execute the preloaded functions contents

(also see "declare -F")

Regards,
Rudy Wieser

On 2023-05-03, R.Wieser wrote:
> Dan,
>
>> What do you mean "preload" ?
>
> executing the script
>
> . ./loadit

Okay, wait. You said this syntax was "running it 'dotted'" in MID
<u2t5re$17b4u$1@dont-email.me> . Now you're saying this is "preloaded".

Do you REALLY mean to say that running the script directly from the
prompt works, and sourcing it does not?

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

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".

--
Cheers, Carlos.

On 2023-05-03 12:29, Dan Purgert wrote:
> On 2023-05-03, R.Wieser wrote:
>> Dan,
>>
>>> What do you mean "preload" ?
>>
>> executing the script
>>
>> . ./loadit
>
> Okay, wait. You said this syntax was "running it 'dotted'" in MID
> <u2t5re$17b4u$1@dont-email.me> . Now you're saying this is "preloaded".
>
> Do you REALLY mean to say that running the script directly from the
> prompt works, and sourcing it does not?

I think he is sourcing a script that contains functions, and then
calling the functions from that bash session.

But the function was named "cleanist()", then he calls "cleanhist".

--
Cheers, Carlos.

On 2023-05-03, Carlos E.R. wrote:
> On 2023-05-03 12:29, Dan Purgert wrote:
>> On 2023-05-03, R.Wieser wrote:
>>> Dan,
>>>
>>>> What do you mean "preload" ?
>>>
>>> executing the script
>>>
>>> . ./loadit
>>
>> Okay, wait. You said this syntax was "running it 'dotted'" in MID
>> <u2t5re$17b4u$1@dont-email.me> . Now you're saying this is "preloaded".
>>
>> Do you REALLY mean to say that running the script directly from the
>> prompt works, and sourcing it does not?
>
> I think he is sourcing a script that contains functions, and then
> calling the functions from that bash session.

Nice catch, I didn't even see he changed it between the two posts to
include a function definition. I need more coffee :)

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

Dan,

> Okay, wait. You said this syntax was "running it 'dotted'" in MID
> <u2t5re$17b4u$1@dont-email.me> . Now you're saying this is "preloaded".

I posted that I tried BOTH, and that the results differ.

> Nice catch, I didn't even see he changed it between the two posts
> to include a function definition.

How come ? Thats what you asked for : an explanation of what I called
"preloaded"

> I need more coffee :)

Yep, you do. :-)

Regards,
Rudy Wieser