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

[Linda Walsh]

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?