Re: [perl #5634] CPAN.pm v1.59 chdirs before looking for perl
Michael G Schwern wrote: No, [...] No, [...] Ack! No! [...] OK, I give up. And I see you've sensibly moved this issue to a new ticket (36539). Patch applied as change 25142. Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
Re: [perl #5634] CPAN.pm v1.59 chdirs before looking for perl
Michael G Schwern wrote:
On Tue, Jul 12, 2005 at 05:25:07PM +0100, Steve Hay wrote:
Why doesn't this work out for you?
Because it should never do that search. In your example you got lucky
because the relative Perl you ran CPAN.pm with happened to match the one in
$Config{binexp}. What if that's not true?
It wasn't quite true. The relative Perl (bin\perl) didn't match
$Config{binexp} (C:\perl\bin). It was the 'perl' bit that matched
$Config{binexp}. And wouldn't that always be the case?
It wasn't so much me getting lucky as you getting unlucky in your
example below. Unlucky, because CPAN::Distribution::perl happens to
trawl through your PATH (where it accidentally found the wrong perl)
before trying $Config{binexp} (where it would have found the right perl).
If you just changed
PATH_COMPONENT: foreach $component (File::Spec-path(),
$Config::Config{'binexp'}) {
to
PATH_COMPONENT: foreach $component ($Config::Config{'binexp'},
File::Spec-path()) {
then your example below would work wouldn't it?
And it may also make sense for
DIST_PERLNAME: foreach $perl_name ($^X, 'perl', 'perl5', perl$]) {
to be changed to
DIST_PERLNAME: foreach $perl_name ('perl', perl$], $^X, 'perl5') {
since 'perl' is very likely to be found in $Config{binexp}.
I agree that it makes much more sense to look for perl sooner rather
than later, and also caching the result is clearly far better than
repeatedly re-searching for something that can't have changed, but I'm
just wondering if there is anything that we can learn from why your
examples fail that can be used to improve the search for perl, given
that the same search code is going to be kept.
Consider the following.
$ cd ~/tmp/
$ which perl
/sw/bin/perl
$ perl -v
This is perl, v5.8.6 built for darwin-thread-multi-2level
blah blah blah
$ ln -s /usr/bin/perl5.8.1 perl
$ ./perl -v
This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level
(with 1 registered patch, see perl -V for more detail)
bleh bleh
$ ./perl -MCPAN -e shell
cpan shell -- CPAN exploration and modules installation (v1.76)
ReadLine support enabled
cpan test Text::Metaphone
CPAN: Storable loaded ok
Going to read /Users/schwern/.cpan/Metadata
Database was generated on Mon, 11 Jul 2005 22:03:40 GMT
Running test for module Text::Metaphone
Running make for M/MS/MSCHWERN/Text-Metaphone-1.96.tar.gz
...etc...
CPAN.pm: Going to build M/MS/MSCHWERN/Text-Metaphone-1.96.tar.gz
Checking if your kit is complete...
Looks good
Writing Makefile for Text::Metaphone
cp Metaphone.pm blib/lib/Text/Metaphone.pm
gcc-3.3 -c -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp
-fno-strict-aliasing -pipe -Os -DVERSION=\1.96\ -DXS_VERSION=\1.96\
-I/sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level/CORE my_memory.c
^
Ding ding ding ding ding! I ran CPAN.pm with 5.8.1 but its building with
5.8.6. Because it chdir'd to the build directory before trying to resolve
my relative $^X it could not find it. So in desperation it started looking
through my PATH and found /sw/bin/perl.
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
Re: [perl #5634] CPAN.pm v1.59 chdirs before looking for perl
On Wed, Jul 13, 2005 at 08:41:48AM +0100, Steve Hay wrote:
It wasn't quite true. The relative Perl (bin\perl) didn't match
$Config{binexp} (C:\perl\bin). It was the 'perl' bit that matched
$Config{binexp}. And wouldn't that always be the case?
No, not if we want a chance to find the perl they ran with.
It wasn't so much me getting lucky as you getting unlucky in your
example below. Unlucky, because CPAN::Distribution::perl happens to
trawl through your PATH (where it accidentally found the wrong perl)
before trying $Config{binexp} (where it would have found the right perl).
If you just changed
PATH_COMPONENT: foreach $component (File::Spec-path(),
$Config::Config{'binexp'}) {
to
PATH_COMPONENT: foreach $component ($Config::Config{'binexp'},
File::Spec-path()) {
then your example below would work wouldn't it?
No, because the Perl I ran exists nowhere in $Config{binexp} nor PATH. Its
sitting in my temp directory. CPAN.pm will never find it unless it looks
in the directory I ran the CPAN shell from. Thus it cannot chdir before
looking for perl if we hope to find the same Perl the user ran CPAN.pm with.
And it may also make sense for
DIST_PERLNAME: foreach $perl_name ($^X, 'perl', 'perl5', perl$]) {
to be changed to
DIST_PERLNAME: foreach $perl_name ('perl', perl$], $^X, 'perl5') {
since 'perl' is very likely to be found in $Config{binexp}.
Ack! No! That means in this situation:
$ which perl5.8.1
/usr/bin/perl5.8.1
$ which perl
/sw/bin/perl
$ perl -v
This is perl, v5.8.6 built for darwin-thread-multi-2level
$ perl5.8.1 -MCPAN -e shell
Its going to look for perl before perl5.8.1 and thus probably pick up
/sw/bin/perl instead of /usr/bin/perl5.8.1
However, putting perl$] before perl5 makes sense. Its better to check
for a Perl of a specific version and then degrade to a more general check.
These days Csprintf perl%vd, $^V is more likely to match (ie. perl5.8.6).
The ordering should probably be: $^X, $versioned_perl, perl$], perl5,
perl. But that's another bug.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Don't try the paranormal until you know what's normal.
-- Lords and Ladies by Terry Prachett
Re: [perl #5634] CPAN.pm v1.59 chdirs before looking for perl
Michael G Schwern via RT wrote:
[schwern - Tue Jul 15 18:31:18 2003]:
The attached patch fixes this bug by the simple method of storing the
Perl we started
with as an absolute path before anything is done. Then perl() can
reference this
information. I can't see how this could go wrong on MacOS.
I've also taken the liberty of speeding up perl() by caching its
result.
This patch was never applied.
I've attached a better patch which simply moves the find perl logic from
individual CPAN::Distribution objects to be a function of the CPAN. The
location of Perl is simply cached in a global.
The (new) patch looks fine to me (not that I'm any CPAN.pm expert), but
before I apply it I'm just curious to understand why the existing code
doesn't work.
On my Win32 system, if I set the PATH to be just
C:\WINDOWS;C:\WINDOWS\system32 and cd to C:\perl then the command
bin\perl -MCPAN -e shell
followed by, say, make Sort::Versions works fine. (My perl binary is
installed as C:\perl\bin\perl.exe)
CPAN::Distribution::make does indeed chdir to the build directory before
calling CPAN::Distribution::perl, but that succeeds in finding perl
(C:\perl\bin\perl.exe) even though there is no bin\perl in the build
directory.
It continues to work even after I insert
$^X = 'bin\\perl'
at the start of CPAN::Distribution::perl to simulate an OS that doesn't
set $^X to an absolute path.
It works because the
DIST_PERLNAME: foreach $perl_name ($^X, 'perl', 'perl5', perl$]) {
PATH_COMPONENT: foreach $component (File::Spec-path(),
$Config::Config{'binexp'}) {
loops succeed when $perl_name is 'perl' and $component is
$Config::Config{'binexp'} (in my case, 'C:\perl\bin').
Why doesn't this work out for you?
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
Re: [perl #5634] CPAN.pm v1.59 chdirs before looking for perl
On Tue, Jul 12, 2005 at 05:25:07PM +0100, Steve Hay wrote:
Why doesn't this work out for you?
Because it should never do that search. In your example you got lucky
because the relative Perl you ran CPAN.pm with happened to match the one in
$Config{binexp}. What if that's not true? Consider the following.
$ cd ~/tmp/
$ which perl
/sw/bin/perl
$ perl -v
This is perl, v5.8.6 built for darwin-thread-multi-2level
blah blah blah
$ ln -s /usr/bin/perl5.8.1 perl
$ ./perl -v
This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level
(with 1 registered patch, see perl -V for more detail)
bleh bleh
$ ./perl -MCPAN -e shell
cpan shell -- CPAN exploration and modules installation (v1.76)
ReadLine support enabled
cpan test Text::Metaphone
CPAN: Storable loaded ok
Going to read /Users/schwern/.cpan/Metadata
Database was generated on Mon, 11 Jul 2005 22:03:40 GMT
Running test for module Text::Metaphone
Running make for M/MS/MSCHWERN/Text-Metaphone-1.96.tar.gz
...etc...
CPAN.pm: Going to build M/MS/MSCHWERN/Text-Metaphone-1.96.tar.gz
Checking if your kit is complete...
Looks good
Writing Makefile for Text::Metaphone
cp Metaphone.pm blib/lib/Text/Metaphone.pm
gcc-3.3 -c -I/sw/include -fno-common -DPERL_DARWIN -no-cpp-precomp
-fno-strict-aliasing -pipe -Os -DVERSION=\1.96\ -DXS_VERSION=\1.96\
-I/sw/lib/perl5-core/5.8.6/darwin-thread-multi-2level/CORE my_memory.c
^
Ding ding ding ding ding! I ran CPAN.pm with 5.8.1 but its building with
5.8.6. Because it chdir'd to the build directory before trying to resolve
my relative $^X it could not find it. So in desperation it started looking
through my PATH and found /sw/bin/perl.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Don't try the paranormal until you know what's normal.
-- Lords and Ladies by Terry Prachett
[perl #5634] CPAN.pm v1.59 chdirs before looking for perl
[schwern - Tue Jul 15 18:31:18 2003]: The attached patch fixes this bug by the simple method of storing the Perl we started with as an absolute path before anything is done. Then perl() can reference this information. I can't see how this could go wrong on MacOS. I've also taken the liberty of speeding up perl() by caching its result. This patch was never applied. I've attached a better patch which simply moves the find perl logic from individual CPAN::Distribution objects to be a function of the CPAN. The location of Perl is simply cached in a global. CPAN.pm.patch Description: Binary data
[perl #5634] CPAN.pm v1.59 chdirs before looking for perl
[schwern - Tue Jul 15 18:31:18 2003]: The attached patch fixes this bug by the simple method of storing the Perl we started with as an absolute path before anything is done. Then perl() can reference this information. I can't see how this could go wrong on MacOS. I've also taken the liberty of speeding up perl() by caching its result. This is still a problem as of CPAN 1.76.
