Re: bash 4.2 breaks source finding libs in lib/filename...

[Pierre Gaston]

On Fri, Mar 2, 2012 at 9:54 AM, Stefano Lattarini <
stefano.lattarini@gmail.com> wrote:

> On 03/02/2012 02:50 AM, Chet Ramey wrote:
> > On 2/29/12 2:42 PM, Eric Blake wrote:
> >
> > In the middle of the histrionics and gibberish, we have the nugget of an
> > actual proposal (thanks, Eric):
> >
> >       [to allow `.' to look anchored relative pathnames up in $PATH]
> >
> >> About the best we can do is accept a patch (are you willing to write it?
> >> if not, quit complaining) that would add a new shopt, off by default, to
> >> allow your desired alternate behavior.
> >
> > Maybe we can have a rational discussion about that.
> >
> Or here is a what it sounds as a marginally better idea to me: Bash could
> start supporting a new environment variable like "BASHLIB" (a' la'
> PERL5LIB)
> or "BASHPATH" (a' la' PYTHONPATH) holding a colon separated (or semicolon
> separated on Windows) list of directories where bash will look for sourced
> non-absolute files (even if they contain a pathname separator) before
> (possibly) performing a lookup in $PATH and then in the current directory.
> Does this sounds sensible, or would it add too much complexity and/or
> confusion?
>

It could be even furthermore separated from the traditional "source" and a
new keyword introduced like "require" a la lisp which would be able to do
things like:

1) load the file, searching in the BASH_LIB_PATH (or other variables) for a
file with optionally the extension .sh or .bash
2) only load the file if the "feature" as not been provided, eg only load
the file once
3) maybe optionally only load the definition and not execute commands
(something I've seen people asking for on several occasions on IRC), for
instance that would allow to have test code inside the lib file or maybe
print a warning that it's a library not to be executed. (No so important
imo)

I think this would benefit the bash_completion project and help them to
split the script so that the completion are only loaded on demand.
(one of the goal mentionned at http://bash-completion.alioth.debian.org/ is
"make bash-completion dynamically load completions")
My understanding is that the
http://code.google.com/p/bash-completion-lib/project did something
like this but that it was not  working entirely as
they wanted.
(I hope some of the devs reads this list)

On the other hand, there is the possibility to add FPATH and autoload like
in ksh93 ...
I haven't think to much about it but my guess is that it would really be
easy to implement a module system with that.

my 2 cents....as I don't have piles of bash lib.