Subject: Re: pkg/32812: Perl broken in 2005Q4: open with shell metas fails
To: None <,,>
From: Anne Bennett <>
List: pkgsrc-bugs
Date: 02/14/2006 01:00:06
The following reply was made to PR pkg/32812; it has been noted by GNATS.

From: Anne Bennett <>
Subject: Re: pkg/32812: Perl broken in 2005Q4: open with shell metas fails
Date: Mon, 13 Feb 2006 19:55:55 -0500

 >     The trace file contains:
 >     16576 sh execve("/disks/nobak/netbsd/netbsd-3.0/pkgsrc/lang/perl5/work/.tools/bin/sh", 0x7f7fffffdeb0, 0x512200) JUSTRETURN
 > Well, now I know what the problem is, but how on *earth* did Perl
 > manage to persuade itself to use *that* file as a the execution shell???
 The Makefile says:
      # Perl embeds the full paths to the following tools in several installed
      # files, so make sure the paths to the ones in ${TOOLS_DIR} aren't used.
      USE_TOOLS+=             hostname ln sed test
      CONFIGURE_ARGS+=        -Daphostname=${TOOLS_HOSTNAME_CMD:Q}
      CONFIGURE_ARGS+=        -Dln=${TOOLS_LN:Q}
      CONFIGURE_ARGS+=        -Dsed=${TOOLS_SED:Q}
      CONFIGURE_ARGS+=        -Dissymlink="${TOOLS_TEST} -h"
 It sounds as though "embedding the full path to a tool in
 ${TOOLS_DIR}" is exactly what happened, and we somehow have to make
 sure that it gets the right path for "sh".  I wonder how many other
 programs are also getting the wrong path...
      # cd /usr/pkgsrc/lang/perl5 && find . -type f \
         | xargs fgrep /disks/nobak/netbsd/netbsd-3.0/pkgsrc/lang/perl5/work/.tools/bin /dev/null
 ... reveals quite a few Makefiles with
   SHELL = /disks/nobak/netbsd/netbsd-3.0/pkgsrc/lang/perl5/work/.tools/bin/sh
 ... which may not be a problem in itself.
 Also "work/perl-5.8.7/lib/" contains several references
 which look suspicious, as does "work/perl-5.8.7/".  Aha, this
 is probably the important one:
   ./work/perl-5.8.7/config.h:#define SH_PATH "/disks/nobak/netbsd/netbsd-3.0/pkgsrc/lang/perl5/work/.tools/bin/sh" /**/
 I added this to the Makefile:
   +CONFIGURE_ARGS+=   -Dsh=/bin/sh
 and at last the problem is fixed!  However:
   (a) Hardcoding the path to /bin/sh may not be the right thing to do
       on all systems.
   (b) I ran strings on /usr/pkg/bin/perl and /usr/pkg/bin/perl, and I
       ran a "find |xargs grep" in /usr/pkg/lib/perl5, to find any
       further instances of the "perl5/work" directory.  Only one file
       mentioned this path: 
 Since I wasn't sure whether the above would come back to bite me
 later, for example when installing modules, I wanted to do the paranoid thing
 by adding this to the Makefile:
   +CONFIGURE_ARGS+=   -Dstartsh=/bin/sh
 ... but this just caused the process to hang at:
   First let's make sure your kit is complete.  Checking...
   The problem whereby "open" fails on a command that contains shell
   metacharacters is fixed by editing the perl5/Makefile to add:
      +CONFIGURE_ARGS+=   -Dsh=/bin/sh
 Ms. Anne Bennett, as a private citizen:
 Also reachable more officially at work: