Re: How does perl know it's environment.
From: Juha Laiho (Juha.Laiho_at_iki.fi)
Date: 07/16/04
- Next message: Gunnar Hjalmarsson: "Re: Avoiding a GET CGI hack attack"
- Previous message: Joe Smith: "Re: Avoiding a GET CGI hack attack"
- In reply to: Alan Stewart: "Re: How does perl know it's environment."
- Next in thread: Joe Smith: "Re: How does perl know it's environment."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 16 Jul 2004 17:52:03 GMT
Alan Stewart <astewart1@cox.net> said:
>On Thu, 15 Jul 2004 13:22:02 GMT, Juha Laiho <Juha.Laiho@iki.fi>
>wrote:
>
>>Alan Stewart <astewart1@cox.net> said:
>>>On Mon, 12 Jul 2004 15:43:27 -0500, TLOlczyk <olczyk2002@yahoo.com>
>>>wrote:
>>>>I've scoured the documentation and have not been able to find
>>>>an an answer to the following question.
>>>>
>>>>Assuming there are no environmental variables set specifically
>>>>for perl. How does perl know where to find it's installed
>>>>packages, where to install packages, location of the library etc.
...
>>"ldd /usr/bin/perl" gives:
>> libperl.so => /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so (0x40017000)
>>(among other libraries -- and no, that path doesn't change just by copying
>>/usr/bin/perl somewhere else; it's hardcoded into the binary)
>
>I assume that if you just copied /usr/bin/perl somewhere, that it
>found libperl.so in LD_LIBRARY_PATH, not from something built into
>/usr/bin/perl
LD_LIBRARY_PATH will be used, if the library is not found from the path
built into the binary, yes. But for packages like Perl (that are rather
straightforward to compile, and compiler tools tend to be readily
available), use of LD_LIBRARY_PATH doesn't make sense. If you build
perl, you install it like you stated in the configure.
>I don't have Unix, so I don't know if it's true there or not. I am
>just inferring from reading the doc on ldd. What do you see if you
>move both and try "perl -V"?
The other include paths stay the same, they don't change.
>>Further, a search through the above shared library file finds:
>
>What kind of search?
strings libperl.so | grep /usr/lib
(so, "strings" will dump all printable sequences of characters
out of a binary file, and "grep" just filters the output to the
lines containing text /usr/lib)
>>in Unix side it's pretty much impossible to even find out where the
>>"currently running" executable is located in the directory hierarchy
>I would expect the OS knows which of many possible paths it used to
>fetch an executable file, even if it is not readily determined by an
>application programmer.
The OS (depending on the Unix variant) may or may not retain that
information, but generally it's of no use, as it cannot be relied upon
(and the information shouldn't be considered to be available for the
application programs).
This is one place where the mindset for Unix and Windows software
developments differ.
In Unix, the location of an executable file shouldn't be used for
locating any corresponding configuration or other auxiliary files.
Either the main configuration file is in some fixed (compiled-in)
location, or the configuration file location is specified by an
environment variable or a command-line parameter. The idea is to
have executable binaries for all programs in one directory (or in
a certain set of directories), and the configuration and auxiliary
files in another set of directories. This f.ex. facilitates the use of
network-shared drives for storing the executables, thus leaving the
configuration files local for each separate machine running the same
set of executables.
In Windows, there's a way for a program to find out from where it
was launched (and as I understand, it's pretty much impossible to do
anything to an executable program while it is in use), so it makes
sense to some extent to use the executable file location for locating
the auxiliary files (but then, doing this makes it harder to share
the executables for several machines while still having per-machine
configuration files).
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
- Next message: Gunnar Hjalmarsson: "Re: Avoiding a GET CGI hack attack"
- Previous message: Joe Smith: "Re: Avoiding a GET CGI hack attack"
- In reply to: Alan Stewart: "Re: How does perl know it's environment."
- Next in thread: Joe Smith: "Re: How does perl know it's environment."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
