[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Linda Walsh
Subject: Re: bash 4.2 breaks source finding libs in lib/filename...
Date: Wed, 29 Feb 2012 16:58:53 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100228 Lightning/0.9 Thunderbird/ Mnenhy/

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

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

 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
 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,

(or /share/vim, or /usr/include/...etc)...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]