tchrist@convex.COM (Tom Christiansen) (02/11/91)
It's hard to know if your current version of perl will run the script you
just got in the mail if you're not always up-to-date with the Latest and
Greatest version of Perl. And just testing $] doesn't always work: what
if you're making use of a syntactic enhancement?
So I came up with an eval wrapper -- check it out:
$Wrapped_Version = '3.044';
$] =~ /(\d+\.\d+).*\nPatch level: (\d+)/;
$Current_Version = sprintf("%5.3f", $1 + $2/1000);
if ( $Wrapped_Version > $Current_Version) {
print STDERR <<EOF;
Warning: $0 wrapped under perl v$Wrapped_Version; current is only v$Current_Version!
Attempting to continue anyway; wrong answers or syntax errors may result.
EOF
}
eval <<'End_Of_Eval_Wrapper';
# ORIGINAL PERL CODE GOES HERE
End_Of_Eval_Wrapper
die $@ if $@;
I was going to put in the magic that uses __LINE__ to fix up the
$@ message, but that fails at PL18, so I can't do that.
This will catch both the things like
dbmopen(%whatis, "$_/whatis", undef) || (warn "$0: dbmopen $_: $!\n",next);
which didn't work at PL18 cause of %whatis not being understood, and also
things like syntax errors by using __LINE__ when that isn't understood yet.
I'd really rather just say "Thou Shalt Run At Least v4.000" and leave it
at that, but I know some people will always use the newest features, and
most people will never be up to speed. Is it worth it to send out scripts
with this kind of wrapper on them?
--tom
--
"All things are possible, but not all expedient." (in life, UNIX, and perl)composer@chem.bu.edu (Jeff Kellem) (02/11/91)
In article <20326:Feb1103:33:0491@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > Say someone jumps into Perl now, and writes some scripts that work under > 3.044. How does he figure out whether they'll work under 3.041 or 3.025 > or older versions? Does he search through the change lists for each > patch and hope he doesn't miss anything? I've been collecting notes which point out when features were added to Perl. At some point, I'll put all of them together in a single, organized list. In the future, I may include this "History of Feature Changes and Enhancements to Perl" as part of a Perl guide. > In shell scripts (Configure, for example) you can test that system > programs have the features you need. Surely there must be a way to do > the same in Perl. Sure. There is a way.. it's called `eval'. If you're want to test things before using them (as you point out doing in shell scripts), you can slap an `eval' around a Perl expression and test `$@' for errors. Of course, the user can always just upgrade to the latest version of Perl.. ;-} Cheers... -jeff Jeff Kellem Internet: composer@chem.bu.edu
tchrist@convex.COM (Tom Christiansen) (02/12/91)
From the keyboard of brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
:In article <1991Feb11.022847.14573@convex.com> tchrist@convex.COM (Tom Christiansen) writes:
:> It's hard to know if your current version of perl will run the script you
:> just got in the mail if you're not always up-to-date with the Latest and
:> Greatest version of Perl.
:
:The problem isn't that the people running the script need to test
:whether their version is new enough. The problem is that the person
:*writing* the script can't even figure out what version he needs.
:
:Say someone jumps into Perl now, and writes some scripts that work under
:3.044. How does he figure out whether they'll work under 3.041 or 3.025
:or older versions? Does he search through the change lists for each
:patch and hope he doesn't miss anything?
:
:As is, all he can do is test for 3.044. This is a shame, because his
:script may be portable to much older versions.
:
:In shell scripts (Configure, for example) you can test that system
:programs have the features you need. Surely there must be a way to do
:the same in Perl.
I originally considered writing a tool that would analyze a perl program
and tell you try to figure out the earliest release it could run on. I
think that's what Dan would like.
The problem is that this is pretty tough. A person writing the script
won't in general know which features are new, or didn't used to work, or
whatever. And the analysis program can't always make the right decisions.
Let's look at a few of these:
$ cd perl/src; grep '^ \* patch[0-9]*: ' *.[chy] | sort -u -t^K +0.8n
patch1: disambiguated word after "sort" better
patch1: grandfathered "format stdout"
patch1: split in a subroutine wrongly freed referenced arguments
patch1: string ordering tests were wrong
patch1: unless was broken when run under the debugger
patch1: vfork now conditionally defined based on VFORK
patch2: !$foo++ was unreasonably illegal
patch2: /[\000]/ didn't work
patch2: /\b$foo/ didn't work
patch2: default args to unary operators didn't work
patch2: local(@foo) didn't work
patch2: non-existent slice values are now undefined rather than null
patch2: orthogonalized the file modes some so we can have <& +<& etc.
patch2: printf %c, %D, %X and %O didn't work right
patch5: constant numeric subscripts get lost inside ?:
patch5: defined $foo{'bar'} should not create element
patch5: grep() occasionally loses arguments or dumps core
patch5: nested foreach on same array didn't work
patch5: y/abcde// didn't work
patch7: " ''$foo'' " didn't parse right
patch7: grandfathered m'pat' and s'pat'repl' to not be package qualifiers
patch7: grep(1,@array) didn't work
patch7: made nested or recursive foreach work right
patch7: select now works on big-endian machines
patch7: send() didn't allow a TO argument
patch9: $0 is now always the command name
patch9: -l FILEHANDLE now disallowed
patch9: /\bfoo/i didn't work
patch9: @_ clobbered by ($foo,$bar) = split
patch9: @array in scalar context now returns length of array
patch9: \d, \w, and \s could misfire on characters with high bit set
patch9: added pipe function
patch9: chdir; coredumped
patch9: grep iterations no longer in the regexp context of previous iteration
patch9: grep now returns number of items matched in scalar context
patch9: grep(s/foo/bar/, @abc = @xyz) modified @xyz rather than @abc
Some of these are pretty easy to check for, like pipe or require or the
other new keyword Some are very very hard. I'd really rather have people
upgrade than try to figure out whether they can run. Most of the patches
are bug fixes, not new functionality. Even just checking new functionality
is non trivial. Is it really worth it?
I get mail from people complaining my scripts don't work for them under
perl2, and there's little I can do for them. One emailer suggested that
each script simply contain a clear marking of what PL it was developed
under. How badly does the perl community want or need something more
than this? Dan, you seem to want more -- do you think an analysis
program as I mentioned above would suit you, even if it didn't test
for bug conditions since fixed?
--tom
--
"All things are possible, but not all expedient." (in life, UNIX, and perl)brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (02/12/91)
In article <1991Feb11.204619.16651@convex.com> tchrist@convex.COM (Tom Christiansen) writes: > I originally considered writing a tool that would analyze a perl program > and tell you try to figure out the earliest release it could run on. I > think that's what Dan would like. Yep. I realize the problem is hard---it's just as hard for me to figure out whether my latest sendmail patches will work on a release earlier than 5.61, for example. But Perl is a restricted environment. There's no reason that it couldn't take a -Z flag to output the patch level used by each feature in a script; provided that you don't hide too much behind an eval, you could figure out the required version without trouble. > Dan, you seem to want more -- do you think an analysis > program as I mentioned above would suit you, even if it didn't test > for bug conditions since fixed? It would certainly help. ---Dan
tchrist@convex.COM (Tom Christiansen) (02/13/91)
From the keyboard of brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
:> Dan, you seem to want more -- do you think an analysis
:> program as I mentioned above would suit you, even if it didn't test
:> for bug conditions since fixed?
:
:It would certainly help.
I've been poking at the problem, and for now it look like Laziness is
going to win out over Impatience: I'm just going to use the version-
checking wrapper I first posted. Making a program that wraps this
stuff around a script that I send out is the easiest way.
I will amend the message to read:
Attempting to continue anyway; wrong answers, coredumps, or syntax
errors may result.
As I found various things that coredump in PL18 scripts that are
just fine in the PL44 ones. I'm hoping that 4.000 will serve as
a reasonable baseline release and ameliorate the problem somewhat.
--tom
--
"All things are possible, but not all expedient." (in life, UNIX, and perl)