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