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

[John Kearney]

On 03/03/2012 09:43 AM, Stefano Lattarini wrote:
> 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'
>>> 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"
>>
> This might be a slightly better interface, yes.
Agreed though include might be a better name than require. and if your
at it why not include <> and include ""

> 
>> 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 :-)
No I don't like that. if you want something like that just use inclusion
protection like every other language.
if [ -z "${__file_sh__:-}" ]; then
  __file_sh__=1


fi


and my source wrapper function actually checks for that variable b4
sourcing the file.
off the top of my head something like this.
[ -n "${!__$(basename "${sourceFile}" .sh)_sh__}" ] || source
"${sourceFile}"

> 
>> 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 ...
> 
> i.e.:
> 
>   # For bash.
>   if [[ -n $BASH_SOURCE ]]; then
>     test code ...
>   fi
> 
Only works if you source from thh command line, not execute.
what you actually have to do is something like this
  # For bash.
  if [[ "$(basename "${0}")" = scriptname.sh ]]; then
    test code ...
  fi


>> 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.

What would be really useful (dreamy eyes) would be namespace support :)

something like this
 { # codeblock
   namespace namespace1
   testvar=s

   { # codeblock
     namespace namespace2
     testvar=s

   }
 }

 treated like this
 namespace1.testvar=s
 namespace1.namespace2.testvar=s



 although non posix this is already kinda supported because you can do
 function test1.ert.3 {
 }

 I mean all you would do is treat the namespace as a variable preamble
 so you'd have something like this to find the function etc
 if [ type "${varname}" ]
 elif [ type "${namespace}${varname}" ]
 else error not found

 wouldn't actually break anything afaik.


> 
> Regards,
>   Stefano
>