On Mon, May 20, 2024 at 7:54 PM Greg Wooledge <g...@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.