How does perl know it's environment.

[TLOlczyk]

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.
Especially in a custom build where the locationsd are in
nontradfitional packages.


The reply-to email address is (e-mail address removed).
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.

 

[A. Sinan Unur]

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.

perl -V

 

[TLOlczyk]

perl -V

I did not ask how i find out these things. I asked how perl knows it.



The reply-to email address is (e-mail address removed).
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.

 

[A. Sinan Unur]

I did not ask how i find out these things. I asked how perl knows it.

I understand and perl -V is the answer.

That information is set at build time (or installation time on Win32).

perl -help

-V[:variable] print configuration summary (or a single Config.pm
variable)

 

[Peter J. Acklam]

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. Especially in a custom build where the locationsd are in
nontradfitional packages.

The paths are compiled into the perl binary. They are specified
when perl is built.

Peter

 

[Tad McClellan]

The paths are compiled into the perl binary. They are specified
when perl is built.

and

perl -V

will show them to you.

 

[Brian McCauley]

The paths are compiled into the perl binary. They are specified
when perl is built.

This is true but on Win32 they can also be specified in the registry
(see perlwin32)

--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\

 

[James Willmore]

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

^^^^^^^^^^^

It's "environment", not "environmental. They are not "green" ... as
someone pointed out to me in this group

Jim

 

[Peter J. Acklam]

and

perl -V

will show them to you.

That reply has been given numerous times already, but it only
shows which paths perl knows about and not *how* perl knows about
them, which was the question here.

Peter

 

[Tintin]

Subject: How does perl know it's environment

How does perl know it is environment? No idea. Perhaps you meant, how does
Perl know its environment.

The reply-to email address is (e-mail address removed).
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

Post here, reply here, read here.

 

[Sherm Pendley]

How does perl know it is environment? No idea. Perhaps you meant, how
does Perl know its environment.

Well, since we're going to nit-pick...

The OP's usage was correct. The question was about "perl" - i.e. the Perl
interpreter often found in /usr/bin. It was not about "Perl" - i.e. the
language that "perl" is designed to execute.

sherm--

 

[Paul Lalli]

Well, since we're going to nit-pick...

The OP's usage was correct. The question was about "perl" - i.e. the Perl
interpreter often found in /usr/bin. It was not about "Perl" - i.e. the
language that "perl" is designed to execute.

I was going to post that too, until I realized Tintin was nitpicking about
"it's" vs "its". Which, in a Perl newsgroup, is far worse than nitpicking
about Perl vs perl.

Paul Lalli

 

[Sherm Pendley]

I was going to post that too, until I realized Tintin was nitpicking about
"it's" vs "its". Which, in a Perl newsgroup, is far worse than nitpicking
about Perl vs perl.

Why is that worse? He used a single-quote. ;-)

sherm--

 

[Tintin]

Well, since we're going to nit-pick...

The OP's usage was correct. The question was about "perl" - i.e. the Perl
interpreter often found in /usr/bin. It was not about "Perl" - i.e. the
language that "perl" is designed to execute.

Touche!

 

[Kevin Collins]

Why is that worse? He used a single-quote. ;-)

Actually, no he did't
^^^^^

Kevin

 

[Alan Stewart]

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.
Especially in a custom build where the locationsd are in
nontradfitional packages.


The reply-to email address is (e-mail address removed).
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.

Since this thread seems to have offered mostly English lessons or
mis-information, I'll offer an answer.

perl knows the path it executed from, uses that to get the lib path,
and gets its configuration from lib/Config.pm.

It doesn't have paths built into the binary and it doesn't use the
Win32 registry.

Try renaming Config.pm and doing "perl -V". See what you get.

Or copy perl.exe and the perlxx.dll to another directory, and do
"perl-V" from there (or copy perl and the perl lib if running *nix -
you didn't say what OS). Same result.

HTH
Alan

 

[Jonathan Stowe]

Since this thread seems to have offered mostly English lessons or
mis-information, I'll offer an answer.

perl knows the path it executed from, uses that to get the lib path,
and gets its configuration from lib/Config.pm.

No not true.

It doesn't have paths built into the binary and it doesn't use the
Win32 registry.

Try renaming Config.pm and doing "perl -V". See what you get.

Try however doing:

perl -e'print "@INC"';

this works fine with the Config.pm there or not.

Yes it does use Config.pm to provide the information with -V but the
@INC isn't part of that, it just fails before it gets to print the @INC
if the Config.pm isn't there.

/J\

 

[Juha Laiho]

....
Since this thread seems to have offered mostly English lessons or
mis-information, I'll offer an answer.

But yet another false one - on Unix, at least.

It doesn't have paths built into the binary and it doesn't use the
Win32 registry.

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

Further, a search through the above shared library file finds:
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0

.... which very much looks like the initial @INC contents.

In Windows it could well be that some locations can be determined by
the installation location of the actual binary file; in Unix side it's
pretty much impossible to even find out where the "currently running"
executable is located in the directory hierarchy (especially given the
facts that a single file may have multiple directory entries in various
places across the directory structure, and that the file might not have
_any_ directory entry by the time it tries to determine from where it was
run).

 

[Alan Stewart]

No not true.


Try however doing:

perl -e'print "@INC"';

this works fine with the Config.pm there or not.

Yes it does use Config.pm to provide the information with -V but the
@INC isn't part of that, it just fails before it gets to print the @INC
if the Config.pm isn't there.

/J\

Well, I might be completely wrong on Unix (I don't have a Unix box to
try), but on my Win XP machine I did this:

C:\test>copy \perl\bin\perl.exe
1 file(s) copied.

C:\test>perl -e "print @INC;"
c:/Perl/libc:/Perl/site/lib.
C:\test>copy \perl\bin\perl58.dll
1 file(s) copied.

C:\test>perl -e "print @INC;"

 

[TLOlczyk]

Well, I might be completely wrong on Unix (I don't have a Unix box to
try),

I find it hard to believe that perl has that information built in.
More likely it has some mechaqnism to find out where.

Consider the following example:
Popfile ( for those not already familiar with it ) is a spam filter
written in perl. People download and install it on their machines.
perl comes with it. There are lots of programs which behave the same
way.

Now given that, you have a perl which installs itself someplace on
your machine. Maybe it's f:/email/programs/popfile, or c:/windows
or d:/programs or ... . Instead a different version may install itself
on UNIX. Perhaps in /usr/local/bin or /usr/popfile of
/home/myaccount/email or /home//hisaccount.

The point is that this precompiled version of perl installs itself in
a random location *and works*. If environment were precompiled
into the binary, then this could not possibly be the case. So it is
definitely not compiled into the binary.




The reply-to email address is (e-mail address removed).
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,

**
Thaddeus L. Olczyk, PhD

There is a difference between
*thinking* you know something,
and *knowing* you know something.