Re: bash 4.2 breaks source finding libs in lib/filename...

[Linda Walsh]

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)...