From @cpansprout

In Snow Leopard, Apple replaced the scripts that come with perl
(pod2html, perlbug, etc.) with wrappers that delegate to the script
with the version number tacked on the end (pod2html5.8.9 or
pod2html5.10.0 [Snow Leopard comes with two versions of perl]). All
these wrappers are actually hard links to the same file.

I was trying to install 5.10.1 over the system perl (with -Dprefix=/
usr), and, since the scripts already installed are all the same file,
psed ended up being installed with a dozen different names, it being
the last script to be installed.

Shouldn’t installperl be unlinking files if they already exist?

Use of uninitialized value in concatenation (.) or string at /usr/bin/
perlbug line 639.
Use of uninitialized value in concatenation (.) or string at /usr/bin/
perlbug line 639.

Flags​:
  category=install
  severity=high

Site configuration information for perl 5.10.1​:

Configured by sprout at Tue Sep 22 08​:35​:48 PDT 2009.

Summary of my perl5 (revision 5 version 10 subversion 1) configuration​:

  Platform​:
  osname=darwin, osvers=10.0.0, archname=darwin-thread-multi-2level
  uname='darwin pint.local 10.0.0 darwin kernel version 10.0.0​: fri
jul 31 22​:47​:34 pdt 2009; root​:xnu-1456.1.25~1release_i386 i386 '
  config_args='-sed -Duseithreads -Dprefix=/usr -Dman3ext=3pm -
Duseshrplib -Dotherlibdirs=/System/Library/Perl/Extras/5.10.0'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=undef, use64bitall=undef, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-fno-common -DPERL_DARWIN -no-cpp-precomp -fno-
strict-aliasing -pipe -fstack-protector -I/usr/local/include',
  optimize='-O3',
  cppflags='-no-cpp-precomp -fno-common -DPERL_DARWIN -no-cpp-
precomp -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/
include'
  ccversion='', gccversion='4.2.1 (Apple Inc. build 5646)',
gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-
protector -L/usr/local/lib'
  libpth=/usr/local/lib /usr/lib
  libs=-ldbm -ldl -lm -lutil -lc
  perllibs=-ldl -lm -lutil -lc
  libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true,
libperl=libperl.dylib
  gnulibc_version=''
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' '
  cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/
usr/local/lib -fstack-protector'

Locally applied patches​:

@​INC for perl 5.10.1​:
  /System/Library/Perl/5.10.1/darwin-thread-multi-2level
  /System/Library/Perl/5.10.1
  /Library/Perl/5.10.1/darwin-thread-multi-2level
  /Library/Perl/5.10.1
  /Library/Perl/5.10.0/darwin-thread-multi-2level
  /Library/Perl/5.10.0
  /Library/Perl/5.8.9
  /Library/Perl/5.8.6
  /Library/Perl/5.8.1
  /Library/Perl
  /Network/Library/Perl/5.10.1/darwin-thread-multi-2level
  /Network/Library/Perl/5.10.1
  /Network/Library/Perl
  /System/Library/Perl/Extras/5.10.0/darwin-thread-multi-2level
  /System/Library/Perl/Extras/5.10.0
  .

Environment for perl 5.10.1​:
  DYLD_LIBRARY_PATH (unset)
  HOME=/Users/sprout
  LANG=en_US.UTF-8
  LANGUAGE (unset)
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)
  PATH=/usr/bin​:/bin​:/usr/sbin​:/sbin​:/usr/local/bin​:/usr/X11/bin​:/
usr/local/bin
  PERL_BADLANG (unset)
  SHELL=/bin/bash

From @obra

On Tue Sep 22 21​:31​:51 2009, sprout@​cpan.org wrote​:

In Snow Leopard, Apple replaced the scripts that come with perl
(pod2html, perlbug, etc.) with wrappers that delegate to the script
with the version number tacked on the end (pod2html5.8.9 or
pod2html5.10.0 [Snow Leopard comes with two versions of perl]). All
these wrappers are actually hard links to the same file.

I was trying to install 5.10.1 over the system perl (with -Dprefix=/
usr), and, since the scripts already installed are all the same file,
psed ended up being installed with a dozen different names, it being
the last script to be installed.

Shouldn’t installperl be unlinking files if they already exist?

So, we talked about "don't do this" in this specific case, but it'd be nice to come
to a conclusion on how best to bulletproof Perl's install procedure against overly
clever vendors.

The RT System itself - Status changed from 'new' to 'open'

From @cpansprout

On Oct 10, 2009, at 12​:27 PM, Jesse via RT wrote​:

On Tue Sep 22 21​:31​:51 2009, sprout@​cpan.org wrote​:

In Snow Leopard, Apple replaced the scripts that come with perl
(pod2html, perlbug, etc.) with wrappers that delegate to the script
with the version number tacked on the end (pod2html5.8.9 or
pod2html5.10.0 [Snow Leopard comes with two versions of perl]). All
these wrappers are actually hard links to the same file.

I was trying to install 5.10.1 over the system perl (with -Dprefix=/
usr), and, since the scripts already installed are all the same file,
psed ended up being installed with a dozen different names, it being
the last script to be installed.

Shouldn’t installperl be unlinking files if they already exist?

So, we talked about "don't do this" in this specific case,

I actually consider the slight possibility of having to type ‘sudo ln
perl5.10.0 perl’ some day far less painful than changing every script
that begins with #!/usr/bin/perl -C. Anyway, I’ve seen some of Apple’s
install code. It is simplistic enough it would probably run under
5.00. I don’t think it will break.

but it'd be nice to come
to a conclusion on how best to bulletproof Perl's install procedure
against overly
clever vendors.

I think the easiest way is to add ‘unlink’ to installperl. Attached is
a patch. (I first tried modifying File​::Copy, but half the tests for
permissions failed.) It does leave a bit of redundancy, in that there
is another unlink a few lines below (in case the copy fails), but I
don’t understand that code. Specifically, why would you chmod a file,
and not its directory, before unlinking? So I thought I’d best leave
that alone, in case it is needed on some system.

From @cpansprout

diff -rup blead/installperl bleadcopy/installperl
--- blead/installperl	2009-10-01 16:57:11.000000000 -0700
+++ bleadcopy/installperl	2009-10-10 17:26:03.000000000 -0700
@@ -692,6 +692,12 @@ sub copy {
 	unless $opts{silent};
     print "  creating new version of $xto\n"
 	if $Is_VMS and -e $to and !$opts{silent};
+    if(!$Is_VMS and $Config{d_link}) {
+        # Some vendors put hard-linked wrapper scripts in their default
+        # perl installations. This would prevent a proper install over the
+        # top of a vendor's perl without the unlink.
+        unlink $to;
+    }
     unless ($opts{notify} or File::Copy::copy($from, $to)) {
 	# Might have been that F::C::c can't overwrite the target
 	warn "Couldn't copy $from to $to: $!\n"

From @nwc10

On Sun, Oct 18, 2009 at 02​:42​:15PM -0700, Father Chrysostomos wrote​:

On Oct 10, 2009, at 12​:27 PM, Jesse via RT wrote​:

On Tue Sep 22 21​:31​:51 2009, sprout@​cpan.org wrote​:

In Snow Leopard, Apple replaced the scripts that come with perl
(pod2html, perlbug, etc.) with wrappers that delegate to the script
with the version number tacked on the end (pod2html5.8.9 or
pod2html5.10.0 [Snow Leopard comes with two versions of perl]). All
these wrappers are actually hard links to the same file.

I was trying to install 5.10.1 over the system perl (with -Dprefix=/
usr), and, since the scripts already installed are all the same file,
psed ended up being installed with a dozen different names, it being
the last script to be installed.

Shouldn?t installperl be unlinking files if they already exist?

So, we talked about "don't do this" in this specific case,

I actually consider the slight possibility of having to type ?sudo ln
perl5.10.0 perl? some day far less painful than changing every script
that begins with #!/usr/bin/perl -C. Anyway, I?ve seen some of Apple?s
install code. It is simplistic enough it would probably run under
5.00. I don?t think it will break.

I still don't think that we want to do this.

Nicholas Clark

From @jkeenan

On Mon Oct 19 01​:14​:19 2009, nicholas wrote​:

On Sun, Oct 18, 2009 at 02​:42​:15PM -0700, Father Chrysostomos wrote​:

On Oct 10, 2009, at 12​:27 PM, Jesse via RT wrote​:

On Tue Sep 22 21​:31​:51 2009, sprout@​cpan.org wrote​:

In Snow Leopard, Apple replaced the scripts that come with perl
(pod2html, perlbug, etc.) with wrappers that delegate to the script
with the version number tacked on the end (pod2html5.8.9 or
pod2html5.10.0 [Snow Leopard comes with two versions of perl]). All
these wrappers are actually hard links to the same file.

I was trying to install 5.10.1 over the system perl (with -Dprefix=/
usr), and, since the scripts already installed are all the same file,
psed ended up being installed with a dozen different names, it being
the last script to be installed.

Shouldn?t installperl be unlinking files if they already exist?

So, we talked about "don't do this" in this specific case,

I actually consider the slight possibility of having to type ?sudo ln
perl5.10.0 perl? some day far less painful than changing every script
that begins with #!/usr/bin/perl -C. Anyway, I?ve seen some of Apple?s
install code. It is simplistic enough it would probably run under
5.00. I don?t think it will break.

I still don't think that we want to do this.

Nicholas Clark

This ticket has generated no correspondence in nearly four years.

Can we conclude that we do not want to modify installperl to delete
files before copying (and thereby enable us to close the ticket)?

Thank you very much.
Jim Keenan

From @cpansprout

On Thu Aug 08 16​:38​:58 2013, jkeenan wrote​:

On Mon Oct 19 01​:14​:19 2009, nicholas wrote​:

On Sun, Oct 18, 2009 at 02​:42​:15PM -0700, Father Chrysostomos wrote​:

On Oct 10, 2009, at 12​:27 PM, Jesse via RT wrote​:

On Tue Sep 22 21​:31​:51 2009, sprout@​cpan.org wrote​:

In Snow Leopard, Apple replaced the scripts that come with perl
(pod2html, perlbug, etc.) with wrappers that delegate to the script
with the version number tacked on the end (pod2html5.8.9 or
pod2html5.10.0 [Snow Leopard comes with two versions of perl]). All
these wrappers are actually hard links to the same file.

I was trying to install 5.10.1 over the system perl (with -Dprefix=/
usr), and, since the scripts already installed are all the same
file,
psed ended up being installed with a dozen different names, it being
the last script to be installed.

Shouldn?t installperl be unlinking files if they already exist?

So, we talked about "don't do this" in this specific case,

I actually consider the slight possibility of having to type ?sudo
ln
perl5.10.0 perl? some day far less painful than changing every
script
that begins with #!/usr/bin/perl -C. Anyway, I?ve seen some of
Apple?s
install code. It is simplistic enough it would probably run under
5.00. I don?t think it will break.

I still don't think that we want to do this.

Nicholas Clark

This ticket has generated no correspondence in nearly four years.

Can we conclude that we do not want to modify installperl to delete
files before copying (and thereby enable us to close the ticket)?

Well, *I* don’t agree with that! :-)

--

Father Chrysostomos

From [Unknown Contact. See original ticket]

On Thu Aug 08 16​:38​:58 2013, jkeenan wrote​:

On Mon Oct 19 01​:14​:19 2009, nicholas wrote​:

On Sun, Oct 18, 2009 at 02​:42​:15PM -0700, Father Chrysostomos wrote​:

On Oct 10, 2009, at 12​:27 PM, Jesse via RT wrote​:

On Tue Sep 22 21​:31​:51 2009, sprout@​cpan.org wrote​:

In Snow Leopard, Apple replaced the scripts that come with perl
(pod2html, perlbug, etc.) with wrappers that delegate to the script
with the version number tacked on the end (pod2html5.8.9 or
pod2html5.10.0 [Snow Leopard comes with two versions of perl]). All
these wrappers are actually hard links to the same file.

I was trying to install 5.10.1 over the system perl (with -Dprefix=/
usr), and, since the scripts already installed are all the same
file,
psed ended up being installed with a dozen different names, it being
the last script to be installed.

Shouldn?t installperl be unlinking files if they already exist?

So, we talked about "don't do this" in this specific case,

I actually consider the slight possibility of having to type ?sudo
ln
perl5.10.0 perl? some day far less painful than changing every
script
that begins with #!/usr/bin/perl -C. Anyway, I?ve seen some of
Apple?s
install code. It is simplistic enough it would probably run under
5.00. I don?t think it will break.

I still don't think that we want to do this.

Nicholas Clark

This ticket has generated no correspondence in nearly four years.

Can we conclude that we do not want to modify installperl to delete
files before copying (and thereby enable us to close the ticket)?

Well, *I* don’t agree with that! :-)

--

Father Chrysostomos

The patch provided by @cpansprout has not gained any endorsements since it was first proposed in 2009. Two former pumpkings have expressed doubt as to its merits.

I no longer have a working Mac, so I can't evaluate this Darwin-specific problem. However, I am very skeptical of the idea that we should be trying to compensate for weird choices made in a "vendor perl" installation by overwriting files in that installation. We have long followed the adage "the system perl is for the system."

I'm taking this ticket for the purpose of closing it in 7 days unless someone wants to re-open the discussion (preferably with suggestions tested on Darwin).

Thank you very much.
Jim Keenan

The patch provided by @cpansprout has not gained any endorsements since it was first proposed in 2009. Two former pumpkings have expressed doubt as to its merits.

I no longer have a working Mac, so I can't evaluate this Darwin-specific problem. However, I am very skeptical of the idea that we should be trying to compensate for weird choices made in a "vendor perl" installation by overwriting files in that installation. We have long followed the adage "the system perl is for the system."

I'm taking this ticket for the purpose of closing it in 7 days unless someone wants to re-open the discussion (preferably with suggestions tested on Darwin).

Closing ticket per previously announced schedule.

Thank you very much.
Jim Keenan