Xref: utzoo comp.lang.perl:801 gnu.utils.bug:932 comp.unix.questions:20716
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!math.lsa.umich.edu!emv
From: emv@math.lsa.umich.edu (Edward Vielmetti)
Newsgroups: comp.lang.perl,gnu.utils.bug,comp.unix.questions
Subject: perl -v, problem with "CVS" version management system
Message-ID: <EMV.90Mar20005445@duby.math.lsa.umich.edu>
Date: 20 Mar 90 05:54:45 GMT
Sender: news@math.lsa.umich.edu
Organization: University of Michigan Math Dept., Ann Arbor MI.
Lines: 39

Larry,

I've started to put software around here under the control
of 'CVS', a version manager that sits on top of RCS.  It's
supposed to cope with the idea of multiple people hacking
on the same code.

I have run into a problem using it to track perl, namely that
perl -v breaks because the RCS IDs are different.  It comes
from these lines in perly.c, 

	case 'v':
	    fputs(rcsid,stdout);
	    fputs("\nCopyright (c) 1989, Larry Wall\n\n\
Perl may be copied only under the terms of the GNU General Public License,\n\
a copy of which can be found with the Perl 3.0 distribution kit.\n",stdout);
	    exit(0);

which dumps out the rcsid as the "version" tag.  The
standard code that I have to decode this does

( $version  ) = $] =~ /(\d+\.\d+).*\nPatch level/;
die "$program: requires at least version 3 of perl\n" 
 	if $version < 3;

but since CVS changes the RCS ID to 1.1.1.1, I lose.

The solution for now is to
	    fputs("3.0\n",stdout);
which should do the right thing regardless, at least until
perl 4.0 comes out (not likely soon) or you go to a scheme
of "perl 3.2, patchlevel 17" (also seems unlikely).

-- 

--Ed

Edward Vielmetti, U of Michigan math dept.
emv@math.lsa.umich.edu