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 <Dest Var Name> <Variable to search> <name>
<test1> [<test2> [<test3> [<test4> ....]]]
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"
return 1
}
# FindInPathVar <Dest Var Name> <Variable to search> <name>
function FindInPathVar {
FindInPathVarExt "${1}" "${PATH}" "${2}" "-x" "-f"
}
# FindInPathVar <Dest Var Name> <Variable to search> <name>
function FindInIncludeVar {
FindInPathVarExt "${1}" "${INCLUDES}" "${2}" "-f"
}
FindInPathVar _RETURN bash
echo "_RETURN=${_RETURN}"
gives you more control anyway, pretty quick and simple.
