[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stefano Lattarini
Subject: Re: bash 4.2 breaks source finding libs in lib/filename...
Date: Sat, 03 Mar 2012 09:43:10 +0100

On 03/03/2012 08:28 AM, Pierre Gaston wrote:
> On Fri, Mar 2, 2012 at 9:54 AM, Stefano Lattarini wrote:
>> 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'
>> 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"
This might be a slightly better interface, yes.

> 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
These sound good :-)

> 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)
... and even python don't do that!  If people care about making the test
code in the module "automatically executable" when the module is run as
a script, they could use an idiom similar to the python one:

  # For python.
  if __name__ == "__main__":
    test code ...


  # For bash.
  if [[ -n $BASH_SOURCE ]]; then
    test code ...

> 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.
Same here -- it was more of a "theoretical suggestion", in the category of
"hey, you know what would be really cool to have?" :-)  But I don't deeply
care about it, personally.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]