Re: bash 4.2 breaks source finding libs in lib/filename...
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): --- Original Message Subject: bash 4.2 breaks source finding libs in lib/filename... Date: Tue, 28 Feb 2012 17:34:21 -0800 From: Linda Walsh To: bug-bash I have several files that ***source*** the ***lib*** files*** by expecting the name of the lib to be checked against PATH -- How look up [lib] files relative to PATH regardless of them having a '/' in them? --- You are welcome! Not that my original email wouldn't have said I was trying to source library files regardless of whether or not a "/" was in them or anything... And 2nd email: Try 'C', if you ***include*** an ***include file*** with "/", it scans for it in each ***.h root.*** (along with other langs given for examples) -- So far, no references to *executing* anything, only including things that have "/" in them... Erics first response: Agreed - as this behavior is _mandated_ by POSIX, for both sh(1) and for ***execlp(2) and friends. --- He switches to talking about 'exec' -- nothing to do with libraries, immediately after Greg posts references to 'command execution' But if thanking Eric works for you, that's fine. [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. what's to discuss. I submit a patch, and you include it. That's what Eric has indicated for you. You can thank him for that as well. As I indicated, that functionality would be controlled by the posix switch -- if you don't want source/. to be able to include hierarchal names, then you can select posix mode -- Eric said that's what he was used to .. so again, we can thank Eric... Given the number of items on my plate, working in multiple languages and hopping from proj to proj (ADHD), my terminology isn't always precise, but I usually manage to say what I mean -- like only talking about sourcing library files -- never mentioning exec or command execution.. Sometimes, I can write well, but often, when things are off the top of my head, ... they may have a blond tinge to them... ;-/
Re: bash 4.2 breaks source finding libs in lib/filename...
On Fri, Mar 2, 2012 at 9:54 AM, Stefano Lattarini < stefano.lattar...@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 centsas I don't have piles of bash lib.
