Re: [PATCH v2 5/8] builtins/source: parse the -i option

[Matheus Afonso Martins Moreira]

> Setting the variable at all is opting in to new behavior, and you do
> that at your own risk, after reading the documentation and deciding
> that this is what you want.

As the user, it should be my prerogative to set the
variable on my environment and/or rc so that I can
organize my sourceable scripts however I want and
have the scripts which enabled the isolated sourcing
just work no matter where I chose to install them.

As the user, I should be able to run shell scripts
regardless of whether they support this or not.
I should be to set this variable on my .bashrc
and enjoy the nice infrastructure it provides
without worrying about whether or not
some script takes it into account.
I shouldn't be forced to choose between
legacy shell scripts which don't support this
and new shell scripts which do. There's no
technical reason why I shouldn't be able
to run both in the same bash, or even
have one type of script source the other.

Environment variables are recursively passed
down the process tree. If you choose the
variable approach, my choice to "opt in"
will get applied recursively as well.
I'll be making that choice for every
script that I run and every script sourced
by those scripts. That's actually a breaking
change that fails to be compatible.

All that could be achieved without incompatibility
by simply adding the -i option to source. Then my
choice remains mine alone when I pass -i to source
while interacting with bash via the terminal.
Then the script writer's choice becomes theirs alone
when they write their scripts. It becomes a local choice,
not a recursive and inheritable one.

The recursive and inheritable nature of environment variables
are useful for programs _after_ they have chosen to use them.
If the presence of the variable becomes a choice unto itself,
that choice will end up being inadvertently forced on others.

> I do not foresee people setting BASH_SOURCE_PATH
> in their basic interactive shell environments and login
> sessions.

That should definitely be foreseen because that's _exactly_
what I plan to do if this feature gets merged.

I will set it on my .bashrc just like this:

    export BASH_SOURCE_PATH="${HOME}"/.local/share/bash/source

Then I will commit that to my dotfiles repository.

> Why would they do that?
> What purpose would it serve?

I will set the variable in order to create a fixed location
for loading libraries. Then I will break up my growing
collection of shell scripts into reusable functions,
put them into separate files and then put those files
in the BASH_SOURCE_PATH. Then I can easily source
those libraries of functions from my bash programs.

The purpose is to be able to more easily write
more complex bash scripts. This will allow me
to write scripts by following a process like:

    source -i terminal
    source -i options

    # use option parsing functions to get inputs
    # compute some useful output
    # color output with terminal functions

> But you wouldn't want it to be set in your other windows.

I absolutely want it set on every bash process,
including interactive ones.

I always want the ability to source the nice functions
that I put effort into writing and debugging and organizing.
I will even add shorthand aliases for them so that they will
be easy to type on the terminal.

> What I'm imagining here is that the variable will be used almost
exclusively by scripts, to set the location of their resource files,
which they source.

I have nothing against that use case but that's not at all
what I'm imagining. For me this is very much a feature
for the _users_ to help them manage their shell script
collections. It should be in no way exclusive to the scripts.

> They're not useful outside of the script which sources them
> so only that script needs to set BASH_SOURCE_PATH

False. The variable will be extremely and directly useful to me
as a bash user. That's why I proposed and implemented it.

I didn't even intend for the scripts to override it.
The whole idea is scripts would give source some symbol
that represents what they need and source would take care
of loading it so that the functions are available. They need not
care where or even what the scripts are, they can just say:

    source -i my-functions

And it gets done.

I have no objections to scripts overriding it at all.
However I don't think that's an argument against
users being able to control their environment just
like they have control over PATH.

  -- Matheus