Re: bash 4.2 breaks source finding libs in lib/filename...
On 3/3/12 5:09 AM, John Kearney wrote: >>> 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. An autoload that uses FPATH is trivial. There are three versions in examples/functions in the bash distribution. They've been there for over ten years. You can, of course, get more complicated. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bash 4.2 breaks source finding libs in lib/filename...
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. Ksh uses the FPATH variable to find things that are sourced in. I found a great package written decades ago by Noah Friedman. I now use it as an integral part of my bash environment. His package uses FPATH to satisfy a 'require' command and each module that can be required has a set of provide statements so you can just require what you need. No need to enhance bash at all. -- Time flies like the wind. Fruit flies like a banana. Stranger things have .0. happened but none stranger than this. Does your driver's license say Organ ..0 Donor?Black holes are where God divided by zero. Listen to me! We are all- 000 individuals! What if this weren't a hypothetical question? steveo at syslang.net
Re: bash 4.2 breaks source finding libs in lib/filename...
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 centsas 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
>
Re: bash 4.2 breaks source finding libs in lib/filename...
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. > 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 ... i.e.: # For bash. if [[ -n $BASH_SOURCE ]]; 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 centsas 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. Regards, Stefano
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.
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 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? Regards, Stefano
Re: bash 4.2 breaks source finding libs in lib/filename...
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. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: RFE: allow bash to have libraries (was bash 4.2 breaks source finding libs in lib/filename...)
On Wednesday 29 February 2012 17:53:21 Linda Walsh wrote: > Eric Blake wrote: > > On 02/29/2012 12:26 PM, Linda Walsh wrote: > >>> Any pathname that contains a / should not be subject to PATH searching. > > > > Agreed - as this behavior is _mandated_ by POSIX, for both sh(1) and for > > execlp(2) and friends. > > Is it that you don't read english as a first language, or are you just > trying to be argumentative?' i'm guessing irony is lost on you ad hominem attacks have no business on this list or any other project. if you can't handle that, then please go away. -mike signature.asc Description: This is a digitally signed message part.
Re: bash 4.2 breaks source finding libs in lib/filename...
Greg Wooledge wrote: On Wed, Feb 29, 2012 at 11:26:06AM -0800, Linda Walsh wrote: Greg Wooledge wrote: Any pathname that contains a / should not be subject to PATH searching. You are alone in this opinion -- as most application don't follow that rule. ?? Try 'C', if you include a include file with "/", it scans for it in each .h root. C does not use the PATH variable to look for #include files. You're playing the 'straight guy', that pretends to be clueless about inferences and such, right, like "Data" or "Spock"...? We are talking about how applications access ***library*** functions. Bash overloads the path for executables (if you have "sourcepath" turned on), as it's library path. I'm not suggesting you use paths with "/" in them to **execute** executable programs -- only for **library** functions that you "include" or "source" (i.e.use "." to read them into your current file. "." or "source" is bash's means of including "library files" Try Perl -- same thing. I'm pretty sure perl does not use the PATH variable to look for whatever it is you're talking about. I'm pretty sure that it translates :: to "/" and allows you to read in libraries in hierarchies and starts looking at any place in your library path. Try 'vim' -- same thing I'm pretty sure ?p?e?r?l? (vim) does not use the PATH variable to look for whatever it is you're talking about. - Ah HAH..."whatever it is you're talking about" -- you don't know what I am even talking about and you are arguing against it? I wonder if eric is in the same boat. You guys... Almost all normal utils take their 'paths to be the 'roots' of trees that contain files. Why should bash be different? Because we are not discussing Bash out of context. But you don't know the context of what we are discussing, so how can you say so? You are entirely wrong. Ha! You don't even know what I'm talking about and you call me wrong? How embarrassing is that? You don't prejudge people or anything do you -- you look at the facts like any good engineer, right? Ahem!... (giggle)... But wait, there's documentation as well: PATH The search path for commands. It is a colon-separated list of directories in which the shell looks for commands (see COMMAND EXECUTION below). COMMAND EXECUTION After a command has been split into words, if it results in a simple command and an optional list of arguments, the following actions are taken. If the command name contains no slashes, the shell attempts to locate it. [...] If the name is neither a shell function nor a builtin, and contains no slashes, bash searches each element of the PATH for a directory containing an executable file by that name. [...] If the search is successful, or if the command name contains one or more slashes, the shell executes the named program in a separate execution environment. --- Thanks! I agree with that. However, I'm not talking about commands. I'm talking about including files as one would include a ".h", or .pm" or .vim file. How do you have organize your libraries of shell functions to not have hard coded paths in them and not all be in 1 dir, and not be in the same place you have your executable 'commands' (since libraries are usually not meant to be executed like commands, but included our 'sourced' (or ".") You must have a large library of shell functions, certainly you don't hard-code paths or put them in an executable dir -- I thought only Windows did that..?? But on *nix, you usually have separate /lib and /bin dirs, no? (or /share/vim, or /usr/include/...etc)...
Re: RFE: allow bash to have libraries (was bash 4.2 breaks source finding libs in lib/filename...)
On 02/29/2012 11:53 PM, Linda Walsh wrote: > > > Eric Blake wrote: > >> On 02/29/2012 12:26 PM, Linda Walsh wrote: >> >>>> Any pathname that contains a / should not be subject to PATH >>>> searching. >> >> Agreed - as this behavior is _mandated_ by POSIX, for both sh(1) >> and for execlp(2) and friends. > > > Is it that you don't read english as a first language, or are you > just trying to be argumentative?' > > I said: ---- 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 > > Why was this functionality removed in non-posix mode? > > So, your arguments are all groundless and pointless, as your entire > arguments stem from posix .. which I specifically said I'm NOT > specifying. If I want posix behavior, I can flick a switch and > have such compatibility. > > however, Bash was designed to EXceeed the limitations and features > of POSIX, so the fact that posix is restrained in this area, is a > perfect reason to allow it -- as it makes it > > >> >>> Pathnames that *start* with '/' are called an "absolute" >>> pathnames, >>> >>> while paths not starting with '/' are relative. >> >> And among the set of relative pathnames, there are two further >> divisions: anchored (contains at least one '/') and unanchored >> (no '/'). PATH lookup is defined as happening _only_ for >> unanchored names. >> >>> Try 'C', if you include a include file with "/", it scans for >>> it in each .h root. >> >> The C compiler _isn't_ doing a PATH search, so it follows >> different rules. >> >>> Almost all normal utils take their 'paths to be the 'roots' of >>> trees that contain files. Why should bash be different? >> >> Because that's what POSIX says. > > --- Posix says to ground paths with "/" in them at the root's of > their paths? But it says differently for BASH? you aren't > making sense. > > All the utils. > > What does man do?... it looks for a "/" separated hierarchy under > EACH entry of MANPATH. > > What does Perl do? It looks for a "/" separated hierarchy under > each entry in lib. > > What does vim do? It looks for a vim-hierarchy under each entry > of it's list of vim-runtimes. > > what does ld do? What does C do? What does C++ do? They all > look for "/" separated hierarchies under a PATH-like root. > > > You claim that behavior is mandated by posix? I didn't know > posix specified perl standards. or vim... but say they do > then why wouldn't you also look for a "/" separated hierarchy under > PATH? > > What does X do? -- a "/" separated hierarchy? > > > What does Microsoft do for registry locations? a "\" separated > hierarchy under 64 or 32-bit registry areas. > > Where do demons look for files? Under a "/" separated hierarchy > that may be root or a pseudo-root... > > All of these utils use "/" separated hierarchies -- none of them > refuse to do a path lookup with "/" is in the file name. The > entire concept of libraries would fail -- as they are organized > hierarchically. but you may not know the library location until > runtime, so you have a path and a hierarchical lookup. > > So why shouldn't Bash be able to look for 'library' functions in a > hierarchy? > > Note -- as we are talking about non-posix mode of BASH, you can't > use POSIX as a justification. > > > As for making another swithc -- there is already a switch -- > 'posix' for posix behavior. > > I'm not asking for a change in posix behavior, so you can continue > using posix mode ... > > > > >> >>> It goes against 'common sense' and least surprise -- given it's >>> the norm in so many other applications. >> >> 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, > > > --- > > I would agree to it being off in posix mode, by default, and on, > by default when not in posix mode... > > > >> allow your desired alternate behavior. But I won't write such a >> patch, and if such a patch is written, I won't use it, because >>
Re: RFE: allow bash to have libraries (was bash 4.2 breaks source finding libs in lib/filename...)
Eric Blake wrote: On 02/29/2012 12:26 PM, Linda Walsh wrote: Any pathname that contains a / should not be subject to PATH searching. Agreed - as this behavior is _mandated_ by POSIX, for both sh(1) and for execlp(2) and friends. Is it that you don't read english as a first language, or are you just trying to be argumentative?' I said: 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 Why was this functionality removed in non-posix mode? So, your arguments are all groundless and pointless, as your entire arguments stem from posix .. which I specifically said I'm NOT specifying. If I want posix behavior, I can flick a switch and have such compatibility. however, Bash was designed to EXceeed the limitations and features of POSIX, so the fact that posix is restrained in this area, is a perfect reason to allow it -- as it makes it Pathnames that *start* with '/' are called an "absolute" pathnames, while paths not starting with '/' are relative. And among the set of relative pathnames, there are two further divisions: anchored (contains at least one '/') and unanchored (no '/'). PATH lookup is defined as happening _only_ for unanchored names. Try 'C', if you include a include file with "/", it scans for it in each .h root. The C compiler _isn't_ doing a PATH search, so it follows different rules. Almost all normal utils take their 'paths to be the 'roots' of trees that contain files. Why should bash be different? Because that's what POSIX says. --- Posix says to ground paths with "/" in them at the root's of their paths? But it says differently for BASH? you aren't making sense. All the utils. What does man do?... it looks for a "/" separated hierarchy under EACH entry of MANPATH. What does Perl do? It looks for a "/" separated hierarchy under each entry in lib. What does vim do? It looks for a vim-hierarchy under each entry of it's list of vim-runtimes. what does ld do? What does C do? What does C++ do? They all look for "/" separated hierarchies under a PATH-like root. You claim that behavior is mandated by posix? I didn't know posix specified perl standards. or vim... but say they do then why wouldn't you also look for a "/" separated hierarchy under PATH? What does X do? -- a "/" separated hierarchy? What does Microsoft do for registry locations? a "\" separated hierarchy under 64 or 32-bit registry areas. Where do demons look for files? Under a "/" separated hierarchy that may be root or a pseudo-root... All of these utils use "/" separated hierarchies -- none of them refuse to do a path lookup with "/" is in the file name. The entire concept of libraries would fail -- as they are organized hierarchically. but you may not know the library location until runtime, so you have a path and a hierarchical lookup. So why shouldn't Bash be able to look for 'library' functions in a hierarchy? Note -- as we are talking about non-posix mode of BASH, you can't use POSIX as a justification. As for making another swithc -- there is already a switch -- 'posix' for posix behavior. I'm not asking for a change in posix behavior, so you can continue using posix mode ... It goes against 'common sense' and least surprise -- given it's the norm in so many other applications. 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, --- I would agree to it being off in posix mode, by default, and on, by default when not in posix mode... allow your desired alternate behavior. But I won't write such a patch, and if such a patch is written, I won't use it, because I'm already used to the POSIX behavior. --- How do you use the current behavior that doesn't do a path lookup if you include a / in the path (not at the beginning), that you would be able to make use of if you added "." to the beginning of your path (either temporarily or permanently...)? How do you organize your hierarchical libraries with bash so they don't have hard coded paths?
Re: bash 4.2 breaks source finding libs in lib/filename...
On 02/29/2012 12:26 PM, Linda Walsh wrote: >> Any pathname that contains a / should not be subject to PATH searching. Agreed - as this behavior is _mandated_ by POSIX, for both sh(1) and for execlp(2) and friends. > Pathnames that *start* with '/' are called an "absolute" pathnames, > > while paths not starting with '/' are relative. And among the set of relative pathnames, there are two further divisions: anchored (contains at least one '/') and unanchored (no '/'). PATH lookup is defined as happening _only_ for unanchored names. > Try 'C', if you include a include file with "/", it scans for it in each > .h root. The C compiler _isn't_ doing a PATH search, so it follows different rules. > Almost all normal utils take their 'paths to be the 'roots' of > trees that contain files. Why should bash be different? Because that's what POSIX says. > > It goes against 'common sense' and least surprise -- given it's the > norm in so many other applications. 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. But I won't write such a patch, and if such a patch is written, I won't use it, because I'm already used to the POSIX behavior. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: bash 4.2 breaks source finding libs in lib/filename...
On Wed, Feb 29, 2012 at 11:26:06AM -0800, Linda Walsh wrote: > Greg Wooledge wrote: > >Any pathname that contains a / should not be subject to PATH searching. > You are alone in this opinion -- as most application don't follow that rule. ?? > Try 'C', if you include a include file with "/", it scans for it in each > .h root. C does not use the PATH variable to look for #include files. > Try Perl -- same thing. I'm pretty sure perl does not use the PATH variable to look for whatever it is you're talking about. > Try 'vim' -- same thing. I'm pretty sure perl does not use the PATH variable to look for whatever it is you're talking about. > Almost all normal utils take their 'paths to be the 'roots' of > trees that contain files. Why should bash be different? Because we are not discussing Bash out of context. We are discussing the PATH environment variable, which is used by the entire operating system right down to the very kernel. The PATH environment variable is ONLY used when the pathname to be resolved does not contain a / character. > It goes against 'common sense' and least surprise -- given it's the > norm in so many other applications. You are entirely wrong. But wait, there's documentation as well: PATH The search path for commands. It is a colon-separated list of directories in which the shell looks for commands (see COMMAND EXECUTION below). COMMAND EXECUTION After a command has been split into words, if it results in a simple command and an optional list of arguments, the following actions are taken. If the command name contains no slashes, the shell attempts to locate it. [...] If the name is neither a shell function nor a builtin, and contains no slashes, bash searches each element of the PATH for a directory containing an executable file by that name. [...] If the search is successful, or if the command name contains one or more slashes, the shell executes the named program in a separate execution environment.
Re: bash 4.2 breaks source finding libs in lib/filename...
Greg Wooledge wrote: On Tue, Feb 28, 2012 at 05:34:21PM -0800, Linda Walsh wrote: How can one get the same behavior as before and look up files relative to PATH regardless of them having a '/' in them? What? That sounds like it WAS a bug before, and you had somehow interpreted it as a feature. And now you're asking to have the bug back. Any pathname that contains a / should not be subject to PATH searching. You are alone in this opinion -- as most application don't follow that rule. Pathnames that *start* with '/' are called an "absolute" pathnames, while paths not starting with '/' are relative. This is fundamental to the OS. Try 'C', if you include a include file with "/", it scans for it in each .h root. Try Perl -- same thing. Try 'vim' -- same thing. Almost all normal utils take their 'paths to be the 'roots' of trees that contain files. Why should bash be different? It goes against 'common sense' and least surprise -- given it's the norm in so many other applications.
Re: bash 4.2 breaks source finding libs in lib/filename...
On Wed, Feb 29, 2012 at 3:30 PM, Greg Wooledge wrote: > On Tue, Feb 28, 2012 at 05:34:21PM -0800, Linda Walsh wrote: >> How can one get the same behavior as before and look up files >> relative to PATH regardless of them having a '/' in them? > > What? That sounds like it WAS a bug before, and you had somehow > interpreted it as a feature. And now you're asking to have the bug > back. > > Any pathname that contains a / should not be subject to PATH searching. > Not sure which version supported that: $ echo $BASH_VERSION;mkdir -p foo/bar; echo echo foo foo/bar/file;PATH=$PWD/foo:$PATH;source bar/file;source foo/bar/file 2.05b.0(1)-release bash2: bar/file: No such file or directory foo $ echo $BASH_VERSION;mkdir -p foo/bar; echo echo foo> foo/bar/file;PATH=$PWD/foo:$PATH;source bar/file;source foo/bar/file 3.2.25(1)-release -bash: bar/file: No such file or directory foo $ echo $BASH_VERSION;mkdir -p foo/bar; echo echo foo foo/bar/file;PATH=$PWD/foo:$PATH;source bar/file;source foo/bar/file 4.0.33(1)-release bash4: bar/file: No such file or directory foo
Re: bash 4.2 breaks source finding libs in lib/filename...
On Tue, Feb 28, 2012 at 05:34:21PM -0800, Linda Walsh wrote: > How can one get the same behavior as before and look up files > relative to PATH regardless of them having a '/' in them? What? That sounds like it WAS a bug before, and you had somehow interpreted it as a feature. And now you're asking to have the bug back. Any pathname that contains a / should not be subject to PATH searching.
bash 4.2 breaks source finding libs in lib/filename...
I have several files that source the lib files by expecting the name of the lib to be checked against PATH -- but this no longer works when the library is in lib/filename. How can one get the same behavior as before and look up files relative to PATH regardless of them having a '/' in them? Why was this functionality removed in non-posix mode? I could even live with it not working in restricted bash, where I could see it might be a security risk, but in standard scripts?
