Subject: Re: pkg/32812: Perl broken in 2005Q4: open with shell metas fails
To: None <pkg-manager@netbsd.org, gnats-admin@netbsd.org,>
From: Anne Bennett <anne@porcupine.montreal.qc.ca>
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 <anne@porcupine.montreal.qc.ca>
To: gnats-bugs@netbsd.org
Cc: 
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/Config_heavy.pl" contains several references
 which look suspicious, as does "work/perl-5.8.7/config.sh".  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: 
       /usr/pkg/lib/perl5/5.8.0/x86_64-netbsd-thread-multi/Config_heavy.pl
 
 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...
 
 
 SUMMARY:
 *******
 
   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
 
 
 Whew!!!
 
 
 Anne.
 -- 
 Ms. Anne Bennett, as a private citizen:  anne@porcupine.montreal.qc.ca
 Also reachable more officially at work:  anne@encs.concordia.ca