Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!convex!usenet From: tchrist@convex.COM (Tom Christiansen) Newsgroups: comp.lang.perl Subject: Re: the version problem Message-ID: <1991Feb11.204619.16651@convex.com> Date: 11 Feb 91 20:46:19 GMT References: <1991Feb11.022847.14573@convex.com> <20326:Feb1103:33:0491@kramden.acf.nyu.edu> Sender: usenet@convex.com (news access account) Reply-To: tchrist@convex.COM (Tom Christiansen) Organization: CONVEX Software Development, Richardson, TX Lines: 87 Nntp-Posting-Host: pixel.convex.com 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)