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.
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...
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 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...
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: Inconsistent quote and escape handling in substitution part of parameter expansions.
On 2/28/12 10:52 AM, John Kearney wrote:
> Actually this is something that still really confuses me as well.
The key is that bash doesn't do quote removal on the `string' part of the
"${param/pat/string}" expansion. The double quotes are key; quote removal
happens when the expansion is unquoted.
Double quotes are supposed to inhibit quote removal, but bash's hybrid
behavior of allowing quotes to escape characters but not removing them
is biting us here.
--
``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: Inconsistent quote and escape handling in substitution part of parameter expansions.
It isn't just the quote removal that is confusing.
The escape character is also not removed and has its special meaning.
and this also confuses me
take the following 2 cases
echo ${a:-$'\''}
'
echo "${a:-$'\''}"
bash: bad substitution: no closing `}' in "${a:-'}"
and take the following 3 cases
echo "${a:-$(echo $'\'')}"
bash: command substitution: line 38: unexpected EOF while looking for
matching `''
bash: command substitution: line 39: syntax error: unexpected end of file
echo ${a:-$(echo $'\'')}
'
echo "${a:-$(echo \')}"
'
This can not be logical behavior.
On 02/29/2012 11:26 PM, Chet Ramey wrote:
> On 2/28/12 10:52 AM, John Kearney wrote:
>> Actually this is something that still really confuses me as
>> well.
>
> The key is that bash doesn't do quote removal on the `string' part
> of the "${param/pat/string}" expansion. The double quotes are key;
> quote removal happens when the expansion is unquoted.
>
> Double quotes are supposed to inhibit quote removal, but bash's
> hybrid behavior of allowing quotes to escape characters but not
> removing them is biting us here.
>
Re: Inconsistent quote and escape handling in substitution part of parameter expansions.
On 2/28/12 11:54 AM, John Kearney wrote: > the match string and the replace string are exhibiting 2 different > behaviors. Yes. Quotes in the match string are handled like quotes in the %% and ## pattern removal expansions: they quote special characters for the matcher and are removed. The double quotes inhibit the quote removal in the replacement. This can be changed, but it's not backwards compatible. -- ``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: Inconsistent quote and escape handling in substitution part of parameter expansions.
On 2/28/12 12:05 PM, Steven W. Orr wrote:
>> Look consider this
>> test=teststring
>>
>>
>> echo "${test//str/""}"
>
> This makes no sense.
It does when you consider that Posix says (still) that quotes inside
the ${} must match and affect how the closing `}' is found.
--
``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: Inconsistent quote and escape handling in substitution part of parameter expansions.
On 2/28/12 1:04 PM, John Kearney wrote:
> bash treats replacement strings inconsistently in double quoted variable
> expansion.
Double-quoted pattern substitution.
> treated as literal because it is printed
> treated as quote char because otherwise it should hang waiting for '
Correct. It acts as a quote character like unquoted ${param/pat/rep}
but does not undergo quote removal because of the double quotes.
--
``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...)
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: Inconsistent quote and escape handling in substitution part of parameter expansions.
On 2/28/12 4:28 PM, John Kearney wrote:
>
> On 02/28/2012 10:05 PM, Chet Ramey wrote:
>> On 2/28/12 12:26 PM, John Kearney wrote:
>>
>>> But that isn't how it behaves.
>>> "${test//str/""}"
>>>
>>> because str is replaced with '""' as such it is treating the double
>>> quotes as string literals.
>>>
>>> however at the same time these literal double quotes escape/quote a
>>> single quote between them.
>>> As such they are treated both as literals and as quotes as such
>>> inconsistently.
>>
>> I don't have a lot of time today, but I'm going to try and answer bits
>> and pieces of this discussion.
>>
>> Yes, bash opens a new `quoting context' (for lack of a better term) inside
>> ${}. Posix used to require it, though after lively discussion it turned
>> into "well, we said that but it's clearly not what we meant."
>>
>> There are a couple of places in the currently-published version of the
>> standard, minus any corregendia, that specify this. The description of
>> ${parameter} reads, in part,
>>
>> "The matching closing brace shall be determined by counting brace levels,
>> skipping over enclosed quoted strings, and command substitutions."
>>
>> The section on double quotes reads, in part:
>>
>> "Within the string of characters from an enclosed "${" to the matching
>> '}', an even number of unescaped double-quotes or single-quotes, if any,
>> shall occur."
>>
>> Chet
>
> yhea but I think the point is that the current behavior is useless.
> there is no case where I want a " to be printed and start a double
> quoted string? and thats the current behavior.
Maybe you don't, but there are several cases in the test suite that do
exactly that, derived from an old bug report.
We don't have to keep the bash-4.2 behavior, but we need to acknowledge
that it's not backwards-compatible.
--
``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: Inconsistent quote and escape handling in substitution part of parameter expansions.
On 2/28/12 5:34 PM, John Kearney wrote:
> the outermost quotes only effect how the final value is handled.
> same as §()
${} doesn't work like $(), and it never has. That's one consequence
of backwards compatibility -- the Bourne shell didn't have $().
> having special behaviour model for that string makes it imposible to
> work with really.
>
> this should actually make it easier for the parser.
It doesn't actually change anything for the parser.
--
``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: Inconsistent quote and escape handling in substitution part of parameter expansions.
On 02/29/2012 03:46 PM, Chet Ramey wrote:
> On 2/28/12 12:05 PM, Steven W. Orr wrote:
>
>>> Look consider this
>>> test=teststring
>>>
>>>
>>> echo "${test//str/""}"
>>
>> This makes no sense.
>
> It does when you consider that Posix says (still) that quotes inside
> the ${} must match and affect how the closing `}' is found.
According to POSIX, the moment you get to:
"${test/
the parse is undefined, and the handling of " and finding the closing
'}' are no longer specified by POSIX. So the question becomes whether
it is smarter to follow the rules for ${test+...} or for ${test%...}
(alas, POSIX does indeed have different rules for determining how " is
treated and how '}' is found in those two setups).
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Inconsistent quote and escape handling in substitution part of parameter expansions.
John Kearney writes: > It isn't just the quote removal that is confusing. > > The escape character is also not removed and has its special meaning. The esacape character is also a quote character, thus also subject to quote removal. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
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
>> 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?
>
>
>
why not just do something like this?
# FindInPathVarExt
[ [ [ ]]]
function FindInPathVarExt {
local -a PathList
IFS=":" read -a PathList <<< "${2}"
for CPath in "${PathList[@]}" ; do
for CTest in "${@:4}"; do
test "${CTest}" "${CPath}/${3}" || continue 2
done
printf -v "${1}" "${CPath}/${3}"
return 0
done
printf -v "${1}" "Not Found"
ret
Re: Inconsistent quote and escape handling in substitution part of parameter expansions.
On 03/01/2012 12:12 AM, Andreas Schwab wrote: > John Kearney writes: > >> It isn't just the quote removal that is confusing. >> >> The escape character is also not removed and has its special >> meaning. > > The esacape character is also a quote character, thus also subject > to quote removal. > > Andreas. > oh wasn't aware of that distinction thx.
Re: Inconsistent quote and escape handling in substitution part of parameter expansions.
On 02/29/2012 11:55 PM, Chet Ramey wrote:
> On 2/28/12 4:28 PM, John Kearney wrote:
>>
>> On 02/28/2012 10:05 PM, Chet Ramey wrote:
>>> On 2/28/12 12:26 PM, John Kearney wrote:
>>>
But that isn't how it behaves.
"${test//str/""}"
because str is replaced with '""' as such it is treating the double
quotes as string literals.
however at the same time these literal double quotes escape/quote a
single quote between them.
As such they are treated both as literals and as quotes as such
inconsistently.
>>>
>>> I don't have a lot of time today, but I'm going to try and answer bits
>>> and pieces of this discussion.
>>>
>>> Yes, bash opens a new `quoting context' (for lack of a better term) inside
>>> ${}. Posix used to require it, though after lively discussion it turned
>>> into "well, we said that but it's clearly not what we meant."
>>>
>>> There are a couple of places in the currently-published version of the
>>> standard, minus any corregendia, that specify this. The description of
>>> ${parameter} reads, in part,
>>>
>>> "The matching closing brace shall be determined by counting brace levels,
>>> skipping over enclosed quoted strings, and command substitutions."
>>>
>>> The section on double quotes reads, in part:
>>>
>>> "Within the string of characters from an enclosed "${" to the matching
>>> '}', an even number of unescaped double-quotes or single-quotes, if any,
>>> shall occur."
>>>
>>> Chet
>>
>> yhea but I think the point is that the current behavior is useless.
>> there is no case where I want a " to be printed and start a double
>> quoted string? and thats the current behavior.
>
> Maybe you don't, but there are several cases in the test suite that do
> exactly that, derived from an old bug report.
>
> We don't have to keep the bash-4.2 behavior, but we need to acknowledge
> that it's not backwards-compatible.
>
>
Personally vote for ksf93 like behavior, was more intuitive for me, not
that I've tested it all that much but the first impression was a good
one. seriously try it out an see which behavior you want to use.
As for backward compatibility. to be honest I think that anybody who
relied on this behavior should be shot ;) Like someone already said the
only sane way to use it now is with a variable.
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 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.
