Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Thu, 5 Jun 2003 13:20:20 -0400
To: cygwin AT cygwin DOT com
Subject: Cygwinperl & tar on Win9x (really tar)
Message-ID: <20030605172020.GG7542@ny-kenton2a-710.buf.adelphia.net>
Mail-Followup-To: cygwin AT cygwin DOT com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
From: somian AT adelphia DOT net (Soren Andersen)

Hello Cygwinauts,

I'd like to report a problem I encountered recently try to run CPAN(.pm)
on Cygwinperl to ... you know what CPAN does.

My system is Win98 and I suspect from absence of reports concerning this
that somehow this isn't affecting people on other-derived M$ Windows
platforms. All of this is vis a vis cygwin on these platforms, of
course.

CPAN fails to be able to make or install modules because the system call
to tar(1) returns an error (generates a SIGSEGV [?] signal) when perl
tries to have tar unroll a module archive. On examination, tar is being
called by perl code in the innards of CPAN.pm, with the old-style flags
(switches) un-prefaced by a hyphen/dash/(-) token, e.g.:

   $ tar xvf foo.tar

On testing, the stackdump can be caused by manually passing arguments
(flags, switches) to tar(1) without a hyphen. I myself always habitually
use the modern GNU-style with tar, i.e. "$ tar -xvzf foo.tar.gz" when I
run `tar' manually or use it in scripts, so this bug never bit me before
CPAN showed it to me.

I can run CPAN by modifying the internal CPAN::Config hash to point
toward this other `tar' program which is really a wrapper script (in
CPAN::Config fully-qualified path spec). This wrapper in turn just calls
real `tar' with flags corrected.

-----SNIP-----8<----------CUT HERE-------------------------------------
#!/bin/bash

declare opflags=''
declare -a tar_args=($@)
if [ $# == 1 ] || [[ $0 != *tar ]] || [ "NUL${tar_args[0]}" == NUL ]
 then
  echo 1>&2 "No args or flags passed to $0, must abort with error!"
  exit 1
 else
  opflags=${tar_args[0]}
fi
if [[ $opflags != -* ]] ; then
  tar_args[0]="-$opflags"
fi

# echo Going to do: "exec /bin/tar ${tar_args[@]}"
exec /bin/tar ${tar_args[@]}
-----SNIP-----8<----------CUT HERE-------------------------------------

Sorry, I don't have the opportunity available to me at present to dig
into winsup/ or tar's source code to try to track this down. I wanted to
get something into the record now in case someone else who might have
more time, gets bitten by this too and wants to try to fix it.

Also, sorry, I am composing this message from Debian GNU/Linux, so I
have not the opportunity to generate a "cygcheck.exe" output file to
attach to this message. My `tar' was from cygwin release 1.13.25 and
then I reverted to the previous one (whatever that was). Both tar
versions manifested the same segfault.

-- 
See my OpenPGP key at https://savannah.gnu.org/people/viewgpg.php?user_id=6050
GnuPG public key fingerprint  | "Only when efforts to reform society have as
 BD26 A5D8 D781 C96B 9936     |  their point of departure the reformation of
 310F 0573 A3D9 4E24 4EA6     |  the inner life -- human revolution -- will
they lead us with certainty to a world of lasting peace and true human security."
                                -- Daisaku Ikeda

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/