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

[Phi Debian]

On Mon, May 20, 2024 at 7:54 PM Greg Wooledge <greg@wooledge.org> wrote:

> On Mon, May 20, 2024 at 07:43:10PM +0200, Andreas Kähäri wrote:
> > On Mon, May 20, 2024 at 05:31:05PM +0000, Matheus Afonso Martins Moreira
> wrote:
> >
> >       PATH=${BASH_SEARCH_PATH-$PATH} . file
> >
> > without the need to add any options to . or to source.  But maybe that
> > too pedestrian?
>
> Are we going in circles yet?  This would clobber the value of PATH for
> the duration of sourcing "file", which would potentially cause commands
> in "file" to break.
>
> hobbit:~$ cat bar
> echo hi | cat
> hobbit:~$ PATH=. source bar
> bash: cat: command not found
>

Yes we are probably circling because of the schizophrenic nature of the
feature.

At the beginning, I think not sure I remember well, the whole idea was to
get bash 'libraries' described as bringing more functions written by other
into a runnable (-x) script. This was perceived (I guess) as an 'include'
but since it was function may be as a 'link' or both combined, and as such
required a special treatment ala -I -L compiler like using INC_PATH,
LIB_PATH kind of thing.

Some thought 'source' was a good candidate for this, except that source is
a read/parse/eval feature while the intention was more a read/parse for the
benefit of the 'importer'

so construct like
hobbit:~$ PATH=. source bar

is perfectly ledgit if we are honest and admit bar is an import only and
execute no code, simply bring functions.

So PATH=$BASH_SOURCE_DIR . greatlib

is the way to go, still assuming libs are functions/vars only and no code
execution.

As soon as the 'library' concept assume that eval is also possible, along
with read/parse, then kaboom we need PATH back so the
PATH=$PATH:/path/to/lib .

Real life package actually require the eval, because it is the way to
configure a 'library' depending the user context.

So back to square one, what we need is source as it is and should not be
broken.

Apparently konsolebox wrote a package manager, and survived the source 'as
is', yet he still advocate for 'enhancement'. I do have a package manager
too, and survived source 'as is' and don't require any enhancement.

'May be' bash could investigate the ksh93/zsh $FPATH autoload, but don't
know if that would be good enough for the initial purpose.

Don't know if that FPATH thing was investigated before, if so, why it was
rejected. If good enough and could be adopted, it would be some convergence.