[26111] in Perl-Users-Digest
Perl-Users Digest, Issue: 8308 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Aug 9 15:32:06 2005
Date: Tue, 9 Aug 2005 12:32:00 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 9 Aug 2005 Volume: 10 Number: 8308
Today's topics:
Perl on OSX <sigzero@gmail.com>
Re: Perl on OSX <cwilbur@chromatico.net>
Re: Perl on OSX <tim@vegeta.ath.cx>
Re: Perl on OSX <sherm@dot-app.org>
Re: Perl on OSX <tim@vegeta.ath.cx>
Re: Perl on OSX <sherm@dot-app.org>
Re: Perl on OSX <BLOCKSPAMfishfry@your-mailbox.com>
Re: Perl on OSX <sherm@dot-app.org>
Re: Perl on OSX <tim@vegeta.ath.cx>
Re: Perl on OSX <sherm@dot-app.org>
Re: Perl on OSX <tim@vegeta.ath.cx>
Perl/DOS how do i check if directories are equivalent . <Random@Task.be>
Re: Perl/DOS how do i check if directories are equivale <sherm@dot-app.org>
Re: Perl/DOS how do i check if directories are equivale <Random@Task.be>
Re: Perl/DOS how do i check if directories are equivale <Random@Task.be>
Re: Perl/DOS how do i check if directories are equivale <tim@vegeta.ath.cx>
Re: Perl/DOS how do i check if directories are equivale <ThomasKratz@REMOVEwebCAPS.de>
Re: Perl/DOS how do i check if directories are equivale <djames@thehub.com.au>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 05 Aug 2005 22:57:25 GMT
From: Robert Hicks <sigzero@gmail.com>
Subject: Perl on OSX
Message-Id: <sigzero-DB9884.18572505082005@news1.east.earthlink.net>
Are you using the Perl that came with OSX (tiger) or are you using
ActiveStates new ActivePerl for OSX? And why or why not?
Robert
------------------------------
Date: Fri, 05 Aug 2005 20:03:05 -0400
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Perl on OSX
Message-Id: <m2oe8cgcee.fsf@ubiquity.chromatico.net>
>>>>> "RH" == Robert Hicks <sigzero@gmail.com> writes:
RH> Are you using the Perl that came with OSX (tiger) or are you
RH> using ActiveStates new ActivePerl for OSX? And why or why not?
I'm using the Perl that came with OSX, because I don't see a point in
installing the ActiveState version.
Charlton
--
cwilbur at chromatico dot net
cwilbur at mac dot com
------------------------------
Date: Sat, 06 Aug 2005 01:21:10 GMT
From: Tim Hammerquist <tim@vegeta.ath.cx>
Subject: Re: Perl on OSX
Message-Id: <slrndf8446.svn.tim@vegeta.saiyix>
Robert Hicks <sigzero@gmail.com> wrote:
> Are you using the Perl that came with OSX (tiger) or are you
> using ActiveStates new ActivePerl for OSX? And why or why not?
There is absolutely no reason to use ActivePerl on OS X, unless
you're terminally addicted to the ppm.
The perl that comes with OS X (Tiger and Panther) is fully
functional. The *only* drawback might be that any modules you
add to the base system installation might be overwritten by an
OS upgrade/patch.
In this case, you have two options: use a separate library
hierarchy and the "use lib" pragma, or build your own perl.
Just grab the src tarball, unpack it, and follow the build
instructions. (You'll need the developers tools from the install
disk to compile.) It should compile w/o error and install in
/usr/local by default. Change your $PATH and the shebang line
in scripts as needed.
ActiveState is for people who don't have/want compilers.
Tim Hammerquist
------------------------------
Date: Fri, 05 Aug 2005 21:31:06 -0400
From: Sherm Pendley <sherm@dot-app.org>
Subject: Re: Perl on OSX
Message-Id: <m28xzfn95x.fsf@Sherm-Pendleys-Computer.local>
Tim Hammerquist <tim@vegeta.ath.cx> writes:
> The perl that comes with OS X (Tiger and Panther) is fully
> functional. The *only* drawback might be that any modules you
> add to the base system installation might be overwritten by an
> OS upgrade/patch.
Please don't spread FUD.
The core modules are installed under /System/Library/Perl, with Apple-
supplied CPAN modules under /System/Library/Perl/Extras. The modules
that you install are under /Library/Perl. Like anything in /Library,
they're not managed by Apple and won't be overwritten by any OS patches.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: Sat, 06 Aug 2005 01:50:37 GMT
From: Tim Hammerquist <tim@vegeta.ath.cx>
Subject: Re: Perl on OSX
Message-Id: <slrndf85rd.svn.tim@vegeta.saiyix>
Sherm Pendley <sherm@dot-app.org> wrote:
> Tim Hammerquist <tim@vegeta.ath.cx> writes:
> > The perl that comes with OS X (Tiger and Panther) is fully
> > functional. The *only* drawback might be that any modules
> > you add to the base system installation might be overwritten
> > by an OS upgrade/patch.
>
> Please don't spread FUD.
>
> The core modules are installed under /System/Library/Perl,
> with Apple- supplied CPAN modules under
> /System/Library/Perl/Extras. The modules that you install are
> under /Library/Perl. Like anything in /Library, they're not
> managed by Apple and won't be overwritten by any OS patches.
I quote "Mac OS X Panther for Unix Geeks", 2ed, p.161:
"Installing CPAN Modules", with no related entries in the errata
at <http://www.oreilly.com/catalog/mpantherunix/errata/>:
: We suggest limiting your customization of the Perl that came
: with Mac OS X, since it's fair game for modification during an
: upgrade or patch. You could either end up modifying something
: that the system depends on, or you could end up with
: a partially broken Perl installation the next time Software
: Update performs a big Mac OS X update.
If my paraphrasing caused incorrect information to be
transmitted, I apologize.
I have not made any heavy updates to the core perl installation,
as I just enjoy having my own build to tinker with, so I can
neither confirm nor deny what the above paragraph states. If
you know the above to be untrue, consider reporting it to
O'Reilly.
HTH,
Tim Hammerquist
------------------------------
Date: Fri, 05 Aug 2005 21:55:09 -0400
From: Sherm Pendley <sherm@dot-app.org>
Subject: Re: Perl on OSX
Message-Id: <m24qa3n81u.fsf@Sherm-Pendleys-Computer.local>
Robert Hicks <sigzero@gmail.com> writes:
> Are you using the Perl that came with OSX (tiger) or are you using
> ActiveStates new ActivePerl for OSX? And why or why not?
I have Perl 5.6.0 (Jaguar), 5.8.1 (Panther), 5.8.6 (Tiger), 5.8.7 (home
grown), and 5.8.7 (ActivePerl).
I use Apple's "cross-development" SDKs to build XS modules and a framework
that links to libperl, using Tiger to build binaries for Jaguar's 5.6.0 and
Panther's 5.8.1.
I'm a trained professional, kids - don't try this at home. ;-)
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: Fri, 05 Aug 2005 18:57:18 -0700
From: fishfry <BLOCKSPAMfishfry@your-mailbox.com>
Subject: Re: Perl on OSX
Message-Id: <BLOCKSPAMfishfry-CDB398.18571805082005@comcast.dca.giganews.com>
In article <sigzero-DB9884.18572505082005@news1.east.earthlink.net>,
Robert Hicks <sigzero@gmail.com> wrote:
> Are you using the Perl that came with OSX (tiger) or are you using
> ActiveStates new ActivePerl for OSX? And why or why not?
>
I downloaded and installed my own source tarball.
------------------------------
Date: Fri, 05 Aug 2005 22:37:40 -0400
From: Sherm Pendley <sherm@dot-app.org>
Subject: Re: Perl on OSX
Message-Id: <m2zmrvlrij.fsf@Sherm-Pendleys-Computer.local>
Tim Hammerquist <tim@vegeta.ath.cx> writes:
> I quote "Mac OS X Panther for Unix Geeks", 2ed, p.161:
> "Installing CPAN Modules", with no related entries in the errata
> at <http://www.oreilly.com/catalog/mpantherunix/errata/>:
>
> : We suggest limiting your customization of the Perl that came
> : with Mac OS X, since it's fair game for modification during an
> : upgrade or patch. You could either end up modifying something
> : that the system depends on, or you could end up with
> : a partially broken Perl installation the next time Software
> : Update performs a big Mac OS X update.
The "customization of the Perl that came with Mac OS X" referred to
above is what some users did with Jaguar: It came with Perl 5.6.0, and
some users deleted /System/Library/Perl and replaced it with a newer
release.
/System is Apple's domain. The Perl interpreter and core modules are
installed in /System/Library/Perl. If you modify them, then sooner or
later you *will* have problems with an OS update.
CPAN modules are installed under /Library/Perl. That is not part of
Apple's domain and won't be overwritten by any OS updates. Installing
CPAN modules is perfectly safe.
> you know the above to be untrue, consider reporting it to
> O'Reilly.
The above is true, the mistake is that installing a CPAN module doesn't
customize the system Perl in any way - they're installed in an entirely
separate directory from the core Perl files.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: Sat, 06 Aug 2005 03:15:22 GMT
From: Tim Hammerquist <tim@vegeta.ath.cx>
Subject: Re: Perl on OSX
Message-Id: <slrndf8aq9.shk.tim@vegeta.saiyix>
Sherm Pendley <sherm@dot-app.org> wrote:
> Tim Hammerquist <tim@vegeta.ath.cx> writes:
> > I quote "Mac OS X Panther for Unix Geeks", 2ed, p.161:
> > "Installing CPAN Modules", with no related entries in the
> > errata at
> > <http://www.oreilly.com/catalog/mpantherunix/errata/>:
[ snip ]
>
> The "customization of the Perl that came with Mac OS X"
> referred to above is what some users did with Jaguar: It came
> with Perl 5.6.0, and some users deleted /System/Library/Perl
> and replaced it with a newer release.
Granted that would tend to break a system. But one would wonder
why the "customization" is mentioned at the beginning of
a chapter entitled "Installing CPAN Modules", rather than
"Upgraded/Installing Perl".
> > you know the above to be untrue, consider reporting it to
> > O'Reilly.
>
> The above is true, the mistake is that installing a CPAN
> module doesn't customize the system Perl in any way - they're
> installed in an entirely separate directory from the core Perl
> files.
Ok, I believe I understand what you're saying. It brings up
just one question.
If a user were to use CPAN to upgrade a core module that, in
it's newest release broke some behavior that OS X depended on,
would the upgraded module replace the existing one? If not,
and the upgraded module is placed in /Library, would the
upgraded module supercede the system version? And if not, what
is the point of upgrading via CPAN?
I realize that this is beside the point I originally argued, but
at this point I want to know for my own system.
TIA,
Tim Hammerquist
------------------------------
Date: Sat, 06 Aug 2005 00:27:56 -0400
From: Sherm Pendley <sherm@dot-app.org>
Subject: Re: Perl on OSX
Message-Id: <m2d5orit9v.fsf@Sherm-Pendleys-Computer.local>
Tim Hammerquist <tim@vegeta.ath.cx> writes:
> Sherm Pendley <sherm@dot-app.org> wrote:
>>
>> The "customization of the Perl that came with Mac OS X"
>> referred to above is what some users did with Jaguar: It came
>> with Perl 5.6.0, and some users deleted /System/Library/Perl
>> and replaced it with a newer release.
>
> Granted that would tend to break a system.
I know of at least one update that was definitely broken by that. An
iTunes update contained a post-install script that used EQ (in caps)
to compare strings. In 5.6 that was allowed, but 5.8 it must be in
lower case. So, when users who had replace /usr/bin/perl tried to
update their iTunes, the update failed.
Apple's instructions for upgrading Jaguar to 5.8 weren't very helpful
either - they resulted in the system 5.6 core being left alone, that's
true. But following them resulted in a 5.8 that was wholly installed
(both core and cpan) in /Library/Perl - with no version-specific
directory! So CPAN modules for 5.6 were visible (but not usable) with
the new 5.8, and both core and cpan modules for 5.8 were visible (but
not usable) from 5.6. Adding a module to either one would overwrite
the same module for the other one.
What a nightmare. But it's history - praise Cthulhu.
> But one would wonder
> why the "customization" is mentioned at the beginning of
> a chapter entitled "Installing CPAN Modules", rather than
> "Upgraded/Installing Perl".
Nobody's perfect - even O'Reilly's authors & editors. In this case I
think O'Reilly simply chose to err on the side of caution, advising
readers to be more careful than is really necessary.
Undoubtedly their caution is due in large part to the mess that was
made of Jaguar. It's been cleaned up now, both the stock version that
Apple ships and the Darwin/Mac OS X hints file. The defaults are safe
and sensible now - which they weren't for 5.8.0.
> Ok, I believe I understand what you're saying. It brings up
> just one question.
>
> If a user were to use CPAN to upgrade a core module that, in
> it's newest release broke some behavior that OS X depended on,
> would the upgraded module replace the existing one?
That's a fair stretch, isn't it? The self-tests for core modules
are pretty darned thorough...
At any rate, the answer is that it depends on how the module was
installed. By default, the core modules appear before CPAN modules
in @INC, so the core module would "mask" a newer one.
But, if the user used the UNINST=1 switch when running "make install",
that allows the module installation machinery to detect and delete an
older core version, allowing the newer one to supercede it.
So yes, it's *possible* for a user to modify the core Perl modules by
installing a newer version from CPAN. But they have to work at it -
it's not the default.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: Sat, 06 Aug 2005 05:48:42 GMT
From: Tim Hammerquist <tim@vegeta.ath.cx>
Subject: Re: Perl on OSX
Message-Id: <slrndf8jpp.f9o.tim@vegeta.saiyix>
Sherm Pendley <sherm@dot-app.org> wrote:
> Tim Hammerquist <tim@vegeta.ath.cx> writes:
[ snip ]
> What a nightmare. But it's history - praise Cthulhu.
:)
> > Ok, I believe I understand what you're saying. It brings up
> > just one question.
> >
> > If a user were to use CPAN to upgrade a core module that, in
> > it's newest release broke some behavior that OS X depended
> > on, would the upgraded module replace the existing one?
>
> That's a fair stretch, isn't it? The self-tests for core
> modules are pretty darned thorough...
It's a huge stretch. :) But a deliberate behavior change in
a module might also cause this, not just a bug in an new
release.
> So yes, it's *possible* for a user to modify the core Perl
> modules by installing a newer version from CPAN. But they have
> to work at it - it's not the default.
Ok. That answers my question(s) nicely. Thanks!
Tim Hammerquist
------------------------------
Date: Mon, 08 Aug 2005 11:25:46 -0400
From: Random Task <Random@Task.be>
Subject: Perl/DOS how do i check if directories are equivalent ...
Message-Id: <_PKJe.3065$6d4.449084@news20.bellglobal.com>
Hi quick question
I have two paths say:
C:\pRoGram Files\Monkey Boy\\\\\\
C:\PRoGraM Files\Monkey BOY
Is there a quick way of telling the directories are the same?
Jim
------------------------------
Date: Mon, 08 Aug 2005 11:55:23 -0400
From: Sherm Pendley <sherm@dot-app.org>
Subject: Re: Perl/DOS how do i check if directories are equivalent ...
Message-Id: <m2slxk4e50.fsf@Sherm-Pendleys-Computer.local>
Random Task <Random@Task.be> writes:
> I have two paths say:
>
> C:\pRoGram Files\Monkey Boy\\\\\\
> C:\PRoGraM Files\Monkey BOY
>
> Is there a quick way of telling the directories are the same?
I'm not certain if it would work on Windows, or with directories, but the
first thing I'd try is doing a stat() on both paths and comparing the inodes.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: Mon, 08 Aug 2005 13:50:01 -0400
From: Random Task <Random@Task.be>
Subject: Re: Perl/DOS how do i check if directories are equivalent ...
Message-Id: <dXMJe.4372$6d4.485086@news20.bellglobal.com>
Sherm Pendley wrote:
> Random Task <Random@Task.be> writes:
>
>
>>I have two paths say:
>>
>>C:\pRoGram Files\Monkey Boy\\\\\\
>>C:\PRoGraM Files\Monkey BOY
>>
>>Is there a quick way of telling the directories are the same?
>
>
> I'm not certain if it would work on Windows, or with directories, but the
> first thing I'd try is doing a stat() on both paths and comparing the inodes.
>
> sherm--
>
Doesn't seem to work on windows :-(
I guess i am stuck using:
- lc
- compare length
- remove trailing \'s until strlen = or no \'s
- compare when equal len and no \'s
------------------------------
Date: Mon, 08 Aug 2005 14:02:52 -0400
From: Random Task <Random@Task.be>
Subject: Re: Perl/DOS how do i check if directories are equivalent ...
Message-Id: <42F79E4C.10309@Task.be>
Sherm Pendley wrote:
> Random Task <Random@Task.be> writes:
>
>
>>I have two paths say:
>>
>>C:\pRoGram Files\Monkey Boy\\\\\\
>>C:\PRoGraM Files\Monkey BOY
>>
>>Is there a quick way of telling the directories are the same?
>
>
> I'm not certain if it would work on Windows, or with directories, but the
> first thing I'd try is doing a stat() on both paths and comparing the inodes.
>
> sherm--
>
here's what i did to get around this ... seems to work ok at first
glance :-)
my $tmp = lc $dir1;
my $tmp2 = lc $dir2;
if ($tmp eq $tmp2)
{
&somemagic();
}
elsif ( length($tmp) < length($tmp2))
{
$tmp=~s/\\/\\\\/g;
$tmp2 =~ s/$tmp//g;
$tmp2 =~ s/\\//g;
if ($tmp2 eq "")
{
&somemagic();
}
}
else #if (length($tmp) > length($tmp2))
{
$tmp2=~s/\\/\\\\/g;
$tmp =~ s/$tmp2//g;
$tmp =~ s/\\//g;
if ($tmp eq "")
{
&somemagic();
}
}
------------------------------
Date: Mon, 08 Aug 2005 18:49:10 GMT
From: Tim Hammerquist <tim@vegeta.ath.cx>
Subject: Re: Perl/DOS how do i check if directories are equivalent ...
Message-Id: <slrndffa95.8j6.tim@vegeta.saiyix>
Sherm Pendley <sherm@dot-app.org> wrote:
> Random Task <Random@Task.be> writes:
> > I have two paths say:
> >
> > C:\pRoGram Files\Monkey Boy\\\\\\
> > C:\PRoGraM Files\Monkey BOY
> >
> > Is there a quick way of telling the directories are the
> > same?
>
> I'm not certain if it would work on Windows, or with
> directories, but the first thing I'd try is doing a stat() on
> both paths and comparing the inodes.
Win32 filesystems do not have inodes. In perlport's stat()
entry:
> device and inode are not meaningful. (Win32)
The Win32::AbsPath module makes this a bit easier, as it
normalizes any paths passed to it, not just relative ones.
sub equiv_paths (
use Win32::AbsPath qw/RelativeToAbsolute/;
my ($path1, $path2) = @_;
# RelativeToAbsolute() does not change case
$path1 = lc RelativeToAbsolute($path1);
$path2 = lc RelativeToAbsolute($path2);
return ( $path1 eq $path2 );
}
HTH,
Tim Hammerquist
------------------------------
Date: Mon, 08 Aug 2005 20:49:30 +0200
From: Thomas Kratz <ThomasKratz@REMOVEwebCAPS.de>
Subject: Re: Perl/DOS how do i check if directories are equivalent ...
Message-Id: <42f7a939$0$11219$bb690d87@news.main-rheiner.de>
Random Task wrote:
> Hi quick question
>
> I have two paths say:
>
> C:\pRoGram Files\Monkey Boy\\\\\\
> C:\PRoGraM Files\Monkey BOY
>
> Is there a quick way of telling the directories are the same?
>
> Jim
Here's one way:
use strict;
use warnings;
use File::Spec::Functions;
my $p1 = 'C:\pRoGram Files\Monkey Boy\\\\\\';
my $p2 = 'C:\PRoGraM Files\Monkey BOY';
print "YEP!\n" if canonpath(uc($p1)) eq canonpath(uc($p2));
Thomas
--
$/=$,,$_=<DATA>,s,(.*),$1,see;__END__
s,^(.*\043),,mg,@_=map{[split'']}split;{#>J~.>_an~>>e~......>r~
$_=$_[$%][$"];y,<~>^,-++-,?{$/=--$|?'"':#..u.t.^.o.P.r.>ha~.e..
'%',s,(.),\$$/$1=1,,$;=$_}:/\w/?{y,_, ,,#..>s^~ht<._..._..c....
print}:y,.,,||last,,,,,,$_=$;;eval,redo}#.....>.e.r^.>l^..>k^.-
------------------------------
Date: Tue, 09 Aug 2005 00:00:01 GMT
From: Damian James <djames@thehub.com.au>
Subject: Re: Perl/DOS how do i check if directories are equivalent ...
Message-Id: <slrndffqc7.14b.djames@puli.home>
On Mon, 08 Aug 2005 11:25:46 -0400, Random Task said:
> I have two paths say:
>
> C:\pRoGram Files\Monkey Boy\\\\\\
> C:\PRoGraM Files\Monkey BOY
>
> Is there a quick way of telling the directories are the same?
One quick and messy way I have resorted to in the past to match
directory names in a case insensitive way is to turn the path
into a glob pattern:
(untested)
lc $name;
$name =~ s/[a-z]/"[$&".uc($&)."]"/eg;
my $file = glob $name;
or somesuch.
You'd probably store the results of the glob() as hash keys,
if you wished to eliminate duplicates.
--Damian
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 8308
***************************************
