Tanalis has asked for the wisdom of the Perl Monks concerning the following question:

I've been doing some work on a colleague's script this morning, adding in some (stand-alone) subroutines that I developed as part of the project as a whole.

This, obviously, was trivial enough, and as the subs had previously been tested, I expected the testing of the overall script to be just as trivial. Interestingly, however, I started getting a run-time error message from Perl, that wasn't picked up using perl -c, or during my own testing of the subroutines:

Missing $ on loop variable at Script.pl line 120
Now, line 120 is the start of one of my subroutines, which contains a foreach loop, and very little else (see below for code). The loop variable does, in fact, have a $, and this error seemed bizzare, all the more so because this didn't come up during previous testing.

After some time investigating this, I found that the problem was being caused by the script's shebang line calling a different version of Perl (5.001) to that that I'd done my testing under (5.004.04). If I changed the shebang to call Perl 5.004, the script functioned perfectly happily. Fortunately, running the rest of the script under Perl 5.004 doesn't impact it at all (not that I'd expect it to), and hence we fixed the problem by simply calling the newer version of Perl.

I'm interested to know whether others have experienced problems like this, with multiple versions of Perl being used by the same development team?

If anyone can offer any insights as to why I see the error, at run-time, not at compile-time, I'd be very interested to hear them as well .. :)

sub process_customer_data { my $_cust_data = shift; my %customer_data; foreach my $id (keys %$_cust_data) { # do stuff } return %customer_data; }

-- Foxcub
A friend is someone who can see straight through you, yet still enjoy the view. (Anon)

Replies are listed 'Best First'.
•Re: Inconsistencies between Perl versions
by merlyn (Sage) on Apr 30, 2003 at 09:30 UTC
    Now, line 120 is the start of one of my subroutines, which contains a foreach loop, and very little else (see below for code). The loop variable does, in fact, have a $, and this error seemed bizzare, all the more so because this didn't come up during previous testing.
    It's right that it's an error in that ancient Perl, although the error is misleading.

    The "my" on a foreach loop variable wasn't introduced until either 5.4 or 5.5 (I don't recall which). The error message was reporting a syntax error from the perspective of Perl 5.1, which just had no clue about such syntax.

    And how in the world are you still running 5.1? There are known security holes in that code! I hope you're not facing the internet with a CGI script running that version.

    -- Randal L. Schwartz, Perl hacker
    Be sure to read my standard disclaimer if this is a reply.

      And how in the world are you still running 5.1? There are known security holes in that code! I hope you're not facing the internet with a CGI script running that version.

      Well, we're using a combination of 5.001 and 5.004 - I guess it's seen as easier to keep legacy scripts working, rather than risk an upgrade and having misson-critical scripts fail. To be honest, I don't know :)

      We're not using it for CGI, it's all internal, in-house scripting basically just to munge some data and dump out reports.

      Thanks for the reply, though, I didn't know "my" on a foreach was introduced so recently :)

      -- Foxcub
      A friend is someone who can see straight through you, yet still enjoy the view. (Anon)

        I guess it's seen as easier to keep legacy scripts working, rather than risk an upgrade and having misson-critical scripts fail.

        Tell us that again after you've had to deal with the aftermath of someone taking advantage of one of the n-plus year old holes.

        Of course I'm terrible about changing the oil in my car, so I don't have much room to lecture on the virtue of preventiveness. :)

Re: Inconsistencies between Perl versions
by PodMaster (Abbot) on Apr 30, 2003 at 10:58 UTC
    Tye has always said rely on your local documentation, and that's what you should do (good lesson, thanks tye).

    That means that if you're reading perl5.5 pod, and youre running perl5.1, you're bound to run into trouble. Now i've checked pre55 pod(perlsyn) and it has no "my" on foreach loop vars ;)

    On a sidenote, http://perl.abigail.nl/History/ is interesting ;)


    MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
    I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests.
    ** The Third rule of perl club is a statement of fact: pod is sexy.

Re: Inconsistencies between Perl versions
by gmpassos (Priest) on May 01, 2003 at 04:22 UTC
    This isn't a problem of multiple development team! Note that from a Perl version to another much things changes, specially the bug fixes! Always try to use a newer version of Perl (stable). If you want a very stable use Perl-5.6.1. And note that we are in Perl-5.8.0, and Perl-5.8.1 is comming to fix some bugs in the previous.

    Note that Perl-5.1 is from before 1995!!! I can't find exactly the year. Perl-5.3 is from 1996! Use at least Perl-5.4 in linux, and on Win32 Perl-5.6.1. See that the source Perl-5.1 doesn't exist in CPAN for download, and you only can find it with old old old RPMs! In other words, don't use it.

    What you should know is that Perl5 is one language, Perl4 other, and Perl6 will be another. So, from Perl-5.1 to Perl-5.2 the changes are like from 1.0 to 2.0 in other softwares! From 5.6.1 to 5.8 (the release versions, since 5.7 was dev) much much things have changed, like PerlIO and specially thread!

    Update: On linux you can install mutiple versions of Perl! You don't need to update the old, just install the new in other place, or in the same place if the architecture of Perl was comipled to mantain multiple versions, but I don't know if 5.1 already have this resource.

    Graciliano M. P.
    "The creativity is the expression of the liberty".

      If you want a very stable use Perl-5.6.1 ... Use at least Perl-5.4 in linux

      Why? You make two very sweeping statements there, with no underlying arguments at all. Later versions obviously have bugfixes, obviously have new features, but the stability of the versions doesn't necessarily change from release to release.

      Perl 5.004, which we (mainly) use, can handle the 100,000 rows of data we throw at it, and output the reports we need quickly and efficiently, without crashing. That's our requirement for stability - and 5.004 meets it.

      In my mind there's very little substance in a "update, because a later version's there" mentality. We don't need bleeding-edge, we need mature, stable code and mature, stable scripts. I'm not saying that later versions of Perl aren't mature and stable (completely the opposite, I'm sure they are), but from my perspective, and the point of view of the other people in the tech group where I work, there's very little potential benefit in spending a weekend upgrading a system and ensuring that everything we have still works. Ultimately, the system we have isn't broken, so why fix it?

      When it comes to mission critical systems, I think it's better to play it safe, and stick/cope with a solution that's guaranteed to work for at least a short while longer, rather than perform an unnecessary upgrade and risk things failing.

      -- Foxcub
      A friend is someone who can see straight through you, yet still enjoy the view. (Anon)

        I'm inclined to agree. We have several 5.002 installations on fairly static systems. If I had to do something new with Perl on those boxes, I'd likely install a newer version, but I'd keep 5.002 as well lest I find a handful of scripts that break after an upgrade. (And, with dozens of scripts, thats likely.) An upgrade might also require upgrading modules, and that could get ugly.

        In the production part of my world, perl usually gets upgraded when the hardware does.

        -sauoq
        "My two cents aren't worth a dime.";