Re: RFE: allow bash to have libraries (was bash 4.2 breaks source finding libs in lib/filename...)

[John Kearney]

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.