From Newsgroup: comp.unix.shell

So I can use either 'source' or '.' to load some custom
stuff but there's no way to desource/unload it?

This implies (maybe) if I only need it for temporay use,
something like: ( . ./fubar.mod; do_something ) just a
one off subshell? Which in the case of a subshell,
more or less squashes any convenience, confused on this.

Was hopeing for something like:

toggle() {

TGL=$((!TGL))
[ $TGL -eq 1 ] && . "$1" || desource "$1"

}
--
:wq
Mike Sanders
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-11-03, Michael Sanders <porkchop@invalid.foo> wrote:

So I can use either 'source' or '.' to load some custom
stuff but there's no way to desource/unload it?

No; your best bet is to think of the process as an isolation
container.

This implies (maybe) if I only need it for temporay use,
something like: ( . ./fubar.mod; do_something ) just a
one off subshell? Which in the case of a subshell,
more or less squashes any convenience, confused on this.

But with the process for isolation, you might as well not make that a
sourced script, but an executed script.

The only advantage is that the script sourced in the subshell sees all
of the functions and variables of the parent without anything having to
be exported through the environment or passed as arguments.

Was hopeing for something like:

toggle() {

TGL=$((!TGL))
[ $TGL -eq 1 ] && . "$1" || desource "$1"

}

A sourced script can do literally anything to the host environment; so "desource" would have to magically turn back time to undo arbitrary
effects.

The practical approach would be to have a protocol for undoing
the effect of a source.

You know, kind of like how a Windows installer produces an
"uninstall.exe" program in the application's directory, and registers
that as a handler for uninstallation. If that is coded properly, it can
clean everything.

A well-coded "make clean" target is another example.

If you source two scripts, you have to be able to select which one
to undo. There has to be some identifier given to a script so that
it can produce a cleanup function corresponding to that name,
which you can then call.

Another idea is to have a naming convention for pairs of scripts. For
every foo.sh that is sourced, you have a foo_u.sh which is the
unsourcer. foo_u.sh is carefully coded to scrub all of the definitions
produced by foo.sh and possibly other effects that sourcing foo.sh.
may have; e.g. cleaning up temporary files and directories, taking
down some service that was started or whatever. foo_u.sh has to be
carefully maintained in parallel and tested.

E.g. if we add a variable to foo.sh, we write a test case which
confirms that the variable exists when foo.sh is sourced, and
taht the variable is gone if foo_u.sh is sourced after that.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 03.11.2025 22:24, Michael Sanders wrote:

So I can use either 'source' or '.' to load some custom
stuff but there's no way to desource/unload it?

This implies (maybe) if I only need it for temporay use,
something like: ( . ./fubar.mod; do_something ) just a
one off subshell? Which in the case of a subshell,
more or less squashes any convenience, confused on this.

Was hopeing for something like:

toggle() {

TGL=$((!TGL))
[ $TGL -eq 1 ] && . "$1" || desource "$1"

}

I usually avoid sourcing (and use other methods); I've just
one case where I use it (and I have a lot of shell scripts).

But to your question; to answer that it might be useful to
get some context information, where and how toggle() is used.
Maybe there's alternatives to the "desource" approach.

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Michael Sanders <porkchop@invalid.foo> wrote or quoted:

So I can use either 'source' or '.' to load some custom
stuff but there's no way to desource/unload it?

I wonder where you got that description of "source"
/loading/ something from.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Mon, 3 Nov 2025 21:24:13 -0000 (UTC), Michael Sanders wrote:

So I can use either 'source' or '.' to load some custom
stuff but there's no way to desource/unload it?

exec $SHELL
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Mon, 3 Nov 2025 21:43:26 -0000 (UTC), Kaz Kylheku wrote:

No; your best bet is to think of the process as an isolation
container.

A solid description.

But with the process for isolation, you might as well not make that a
sourced script, but an executed script.

Was hoping the sourced script would only contain functions...

The only advantage is that the script sourced in the subshell sees all
of the functions and variables of the parent without anything having to
be exported through the environment or passed as arguments.

Yeah I read you here: that could be good or pollute name space.

A sourced script can do literally anything to the host environment; so "desource" would have to magically turn back time to undo arbitrary
effects.

Arugh 'arbitrary' does not bode well.

A well-coded "make clean" target is another example.

Hey! That's a cool idea...

If you source two scripts, you have to be able to select which one
to undo. There has to be some identifier given to a script so that
it can produce a cleanup function corresponding to that name,
which you can then call.

Another idea is to have a naming convention for pairs of scripts. For
every foo.sh that is sourced, you have a foo_u.sh which is the
unsourcer. foo_u.sh is carefully coded to scrub all of the definitions produced by foo.sh and possibly other effects that sourcing foo.sh.
may have; e.g. cleaning up temporary files and directories, taking
down some service that was started or whatever. foo_u.sh has to be
carefully maintained in parallel and tested.

E.g. if we add a variable to foo.sh, we write a test case which
confirms that the variable exists when foo.sh is sourced, and
taht the variable is gone if foo_u.sh is sourced after that.

Thanks Kaz, your reply is laden with ideas to try (I wake up in
a new world everyday).
--
:wq
Mike Sanders
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Mon, 3 Nov 2025 22:48:39 +0100, Janis Papanagnou wrote:

But to your question; to answer that it might be useful to
get some context information, where and how toggle() is used.
Maybe there's alternatives to the "desource" approach.

Just sort of thinking out loud truth be known Janis. More or
less a way to branch (well right now its just a toggle but I
could expand it with case statements). Please see my reply
to Lawrence. Its short but perhaps conveys the idea better.

Just learning my around =)
--
:wq
Mike Sanders
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Mon, 3 Nov 2025 23:05:52 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Mon, 3 Nov 2025 21:24:13 -0000 (UTC), Michael Sanders wrote:

So I can use either 'source' or '.' to load some custom
stuff but there's no way to desource/unload it?

exec $SHELL

Hmm...

toggle() {

TGL=$((!TGL))
[ $TGL -eq 1 ] && . script2 || exec $SHELL -c script1 "entry_function" "$TGL"

}

1. (call me pessimistic but..) $TGL will loose scope on exec unless I pass it along?

2. $SHELL -c or -i or -L?
--
:wq
Mike Sanders
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

Janis, if you read this quick question...

Are using +ng in your email address as a
tag/hook/filter for email?

I might try that too...
--
:wq
Mike Sanders
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-11-03, Michael Sanders <porkchop@invalid.foo> wrote:

On Mon, 3 Nov 2025 21:43:26 -0000 (UTC), Kaz Kylheku wrote:

No; your best bet is to think of the process as an isolation
container.

A solid description.

But with the process for isolation, you might as well not make that a
sourced script, but an executed script.

Was hoping the sourced script would only contain functions...

The only advantage is that the script sourced in the subshell sees all
of the functions and variables of the parent without anything having to
be exported through the environment or passed as arguments.

Yeah I read you here: that could be good or pollute name space.

A sourced script can do literally anything to the host environment; so
"desource" would have to magically turn back time to undo arbitrary
effects.

Arugh 'arbitrary' does not bode well.

A well-coded "make clean" target is another example.

Hey! That's a cool idea...

If you source two scripts, you have to be able to select which one
to undo. There has to be some identifier given to a script so that
it can produce a cleanup function corresponding to that name,
which you can then call.

Another idea is to have a naming convention for pairs of scripts. For
every foo.sh that is sourced, you have a foo_u.sh which is the
unsourcer. foo_u.sh is carefully coded to scrub all of the definitions
produced by foo.sh and possibly other effects that sourcing foo.sh.
may have; e.g. cleaning up temporary files and directories, taking
down some service that was started or whatever. foo_u.sh has to be
carefully maintained in parallel and tested.

E.g. if we add a variable to foo.sh, we write a test case which
confirms that the variable exists when foo.sh is sourced, and
taht the variable is gone if foo_u.sh is sourced after that.

Thanks Kaz, your reply is laden with ideas to try (I wake up in
a new world everyday).

Here is an example project, a Bash "extension", which contains
provisions for re-loading.

https://www.kylheku.com/cgit/basta/about/

Basta provides code that runs in your current interactive shell session
and must be sourced into it.

But from time to time users might want to "hot reload" it.

Most of the time that will work fine, but someone jumping from
a really old version to new might need to perform a more "deep reset";
for that I provide the function "basta.cleanup". You can find it in https://www.kylheku.com/cgit/basta/tree/basta.sh
basta.cleanup doesn't delete everything, but it does what is necessary: removing hooks, killing the timer alarm process, resetting the
screen, and clearing a certain global variable that is part of
an array. In sort, everything needed so that the next time this is
sourced, it will be freshly initialized.

And also there are certain coding techniques in the file which
are defensive against reloads, like the variable definition
section on top where we have things like:

basta_scroll_lines=${basta_scroll_lines-0}

I.e. only initialize this variable to 0 if it is unset.

That is inspired by the Common Lisp defvar:

(defvar *scroll-lines* 0)

If *scoll-lines* already exists, then defvar has no effect;
the 0 is not evaluated and not stored into the variable.
defvar has a cousin, defparameter, which always assigns.
You use the correct one of the two when thinking about
the requirements of your code in relation to hot reloading.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-11-04, Michael Sanders <porkchop@invalid.foo> wrote:

Janis, if you read this quick question...

Are using +ng in your email address as a
tag/hook/filter for email?

Gmail supports that too. If you have your.local.part@gmail.com,
you also have the entire space of your.local.part+suffix@gmail.com.

All those addresses route to your inbox and you can use that
for filtering.

It has disadvantages in that it does not create a true "throwaway"
e-mail address that you can later disable so that it doesn't route.

Also, some asshole online services know about this scheme and strip
the + part away. I.e. you create an account with the assholes,
and give themn "your.local.part+suffix@gmail.com", and later they
spam you, removing the + part.

I run a self-hosted app called Tamarind (developed myself) which
gives me a simple web GUI for managing randomly generated
throwaway e-mail addresses like <643-408-1753@kylheku.com>.

The "database" of these is maintained right in the /etc/aliases
file along with some metadata: creation date and description field.

When I create one of these with a click, it instantly begins routing to
my inbox. When I delete it, it is gone; any traffic for it
goes SMTP reject.

These aliases also punch through anti-spam checks: very good for
use as registration e-mails with new services.

Tamarind stands for "throw-away mail alias randomization is
not defeatable", haha!
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 04.11.2025 01:29, Michael Sanders wrote:

Janis, if you read this quick question...

Are using +ng in your email address as a
tag/hook/filter for email?

I'm using that suffix to see whether some bots might have picked
the email address from Usenet. - Of course any bot with a minimum
prudence would handle that, so it's mostly just a sign of my
helplessness concerning spam. - But the address is a valid address,
so I'm reachable by that, although not in a timely manner; since I
don't inspect that mailbox that often - on-topic themes are better
exchanged here in Usenet).

Janis

I might try that too...

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Tue, 4 Nov 2025 00:51:58 -0000 (UTC), Kaz Kylheku wrote:

Tamarind stands for "throw-away mail alias randomization is
not defeatable", haha!

Chuckle, you are quite creative Kaz.
--
:wq
Mike Sanders
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Tue, 4 Nov 2025 17:03:01 +0100, Janis Papanagnou wrote:

I'm using that suffix to see whether some bots might have picked
the email address from Usenet. - Of course any bot with a minimum
prudence would handle that, so it's mostly just a sign of my
helplessness concerning spam. - But the address is a valid address,
so I'm reachable by that, although not in a timely manner; since I
don't inspect that mailbox that often - on-topic themes are better
exchanged here in Usenet).

Thanks.
--
:wq
Mike Sanders
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-11-04, Kaz Kylheku <643-408-1753@kylheku.com> wrote:

On 2025-11-04, Michael Sanders <porkchop@invalid.foo> wrote:

Janis, if you read this quick question...

Are using +ng in your email address as a
tag/hook/filter for email?

Gmail supports that too. If you have your.local.part@gmail.com,
you also have the entire space of your.local.part+suffix@gmail.com.

All those addresses route to your inbox and you can use that
for filtering.

It has disadvantages in that it does not create a true "throwaway"
e-mail address that you can later disable so that it doesn't route.

You can with procmail. I have multiple addresses that use that
technique. I refer to the part after the + as a tag, and keep a list
of authorized tags in a file that procmail checks. If a tag isn't
present, the mail can be either dropped or bounced, at my discretion.
That way, I can disable the address by either removing or commenting
out the tag.

Of course, that means the mail isn't rejected outright by the server.
That would require that the server check my authorized tags file before accepting the mail instead of procmail checking it after it's already
been accepted, which I guess could be done if I had control of the
server, which I don't have for the addresses where I have this
implemented.

I also have a separate tag file for tags that must a date in YYMMDD
format appended, and that date must be within a four day window, which
prevents spammers from spamming an address I've posted in a public
place, like usenet. See my signature and the address in the headers
of this message.

Also, some asshole online services know about this scheme and strip
the + part away. I.e. you create an account with the assholes,
and give themn "your.local.part+suffix@gmail.com", and later they
spam you, removing the + part.

That won't work for my system. I also use a whitelist for mail that
doesn't use a tag, so no one can send me mail if I haven't whitelisted
their address. I have procmail check my whitelist as well. I also
have the ability to whitelist entire mail servers by either IP address
or domain name by checking the last "Received:" line (the last in
chronological order, which is the first in the headers).

I run a self-hosted app called Tamarind (developed myself) which
gives me a simple web GUI for managing randomly generated
throwaway e-mail addresses like <643-408-1753@kylheku.com>.

That has the advantage that there is no "+", which some web sites refuse
to accept as valid.
--
To reply via e-mail, replace "YYMMDD" with the current date in the
appropriate format, or your mail will bounce. Removing the + and
everything that follows in my username will also cause your mail to
bounce. All mail from a nyx server IP address is whitelisted, so this
won't be necessary. Details: https://nyx.net/~cmartin/HowToEmailMe
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 05.11.2025 12:51, Chuck Martin wrote:

On 2025-11-04, Kaz Kylheku <643-408-1753@kylheku.com> wrote:

[ snip interesting means to handle mail and spam ]

I run a self-hosted app called Tamarind (developed myself) which
gives me a simple web GUI for managing randomly generated
throwaway e-mail addresses like <643-408-1753@kylheku.com>.

That has the advantage that there is no "+", which some web sites refuse
to accept as valid.

I wouldn't have thought that servers refuse valid email-addresses.
(I assume they're valid.)
So it's a "political" issue of the individual web-server operator?
Would it be worth, in the first place, to use such services then?
(If some server annoys me with behavior like that I subsequently
just ignore it, typically.)

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In comp.unix.shell, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

I wouldn't have thought that servers refuse valid email-addresses.

I think the issue is more "email address 'validation'" that doesn't
understand email addresses.

So it's a "political" issue of the individual web-server operator?

Probably more ignorance than politics, but I did have a mailing list
operator refuse to support "*" as a local part for political reasons
once.

Elijah
------
also had UUCP site complaints about "#" as a localpart (ages ago)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Wed, 5 Nov 2025 22:14:40 -0000 (UTC), Eli the Bearded wrote:

Probably more ignorance than politics, but I did have a mailing list
operator refuse to support "*" as a local part for political reasons
once.

Elijah ------
also had UUCP site complaints about "#" as a localpart (ages ago)

I dimly remember some years ago, there was an interesting security hole of some kind arising from the different in treatment of rCL+rCY parts in email addresses in Gmail versus, I think, MicrosoftrCOs outlook.com. I canrCOt remember the details, but it did involve routing a message between the
two, where on one side the two addresses would be seen as different,
whereas on the other side they would be seen as the same.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-11-05, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 05.11.2025 12:51, Chuck Martin wrote:

On 2025-11-04, Kaz Kylheku <643-408-1753@kylheku.com> wrote:

[ snip interesting means to handle mail and spam ]

I run a self-hosted app called Tamarind (developed myself) which
gives me a simple web GUI for managing randomly generated
throwaway e-mail addresses like <643-408-1753@kylheku.com>.

That has the advantage that there is no "+", which some web sites refuse
to accept as valid.

I wouldn't have thought that servers refuse valid email-addresses.
(I assume they're valid.)

As Eli said, it's validation, usually done with JavaScript.

So it's a "political" issue of the individual web-server operator?

Again, as Eli said, it's ignorance. The only real way to validate an
e-mail address is to attempt to send mail to it and see if it gets
through. If the intended recipient can reply to e-mail sent to the
address for confirmation or follow a link to a confirmation URL, then
the address must be valid.

Would it be worth, in the first place, to use such services then?
(If some server annoys me with behavior like that I subsequently
just ignore it, typically.)

I would tend to agree, but sometimes it's necessary. For example, if
it's your bank, or a government agency you need to deal with. Also,
I recently came across this issue when trying to sign up for a free
Proton VPN account. You'd think Proton wouldn't be this ignorant,
but evidently not.
--
To reply via e-mail, replace "YYMMDD" with the current date in the
appropriate format, or your mail will bounce. Removing the + and
everything that follows in my username will also cause your mail to
bounce. All mail from a nyx server IP address is whitelisted, so this
won't be necessary. Details: https://nyx.net/~cmartin/HowToEmailMe
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <slrn10gp2hc.2gtgg.cmartin+usenetYYMMDD@nyx2.nyx.net>,
Chuck Martin <cmartin+usenetYYMMDD@nyx.net> wrote:
...

To reply via e-mail, replace "YYMMDD" with the current date in the >appropriate format, or your mail will bounce. Removing the + and
everything that follows in my username will also cause your mail to
bounce. All mail from a nyx server IP address is whitelisted, so this
won't be necessary. Details: https://nyx.net/~cmartin/HowToEmailMe

Wouldn't it be a lot easier for people to just post to the group and not
bother with email?

I have a strong anti-feeling about the concept of emailing stuff to people anyway; it is (almost) always better to just post to the group/list.

In particular, I absolutely hate it when people on mailing lists insist on emailing me copies as well as posting to the list. Just post to the list
and be done with it!

And, given that the spam/malware problem has basically destroyed the
concept of email in general, isn't it better to just put your email address
as nowhere@nowhere.invalid and be done with it?

Note, BTW, that none of this applies to me personally. I've never had a problem with people spamming the (perfectly valid) email address from which
I post, but for people who do, this advice applies.
--
Elect a clown, expect a circus.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-11-06, Kenny McCormack <gazelle@shell.xmission.com> wrote:

In article <slrn10gp2hc.2gtgg.cmartin+usenetYYMMDD@nyx2.nyx.net>,
Chuck Martin <cmartin+usenetYYMMDD@nyx.net> wrote:
...

To reply via e-mail, replace "YYMMDD" with the current date in the >>appropriate format, or your mail will bounce. Removing the + and >>everything that follows in my username will also cause your mail to
bounce. All mail from a nyx server IP address is whitelisted, so this >>won't be necessary. Details: https://nyx.net/~cmartin/HowToEmailMe

Wouldn't it be a lot easier for people to just post to the group and not bother with email?

I have a strong anti-feeling about the concept of emailing stuff to people anyway; it is (almost) always better to just post to the group/list.

In general, I would agree, and I don't usually get private replies by
e-mail, but I figured someone may want to reply about something they
feel is off-topic in the newsgroup. I'd like to give them that option,
while still avoiding getting spammed.

And, given that the spam/malware problem has basically destroyed the
concept of email in general, isn't it better to just put your email address as nowhere@nowhere.invalid and be done with it?

I refuse to let the spammers win. I still consider e-mail to be good
way to communicate, and considering I don't do social networking, it's
the only way for people to communicate with me, other than phone and
text messages, which may not always be ideal.
--
To reply via e-mail, replace "YYMMDD" with the current date in the
appropriate format, or your mail will bounce. Removing the + and
everything that follows in my username will also cause your mail to
bounce. All mail from a nyx server IP address is whitelisted, so this
won't be necessary. Details: https://nyx.net/~cmartin/HowToEmailMe
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-11-07, Chuck Martin <cmartin+usenetYYMMDD@nyx.net> wrote:
[...]

Good to see another of us retaining the hyphen in rCye-mailrCO!

Rob
--- Synchronet 3.21a-Linux NewsLink 1.2