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

Hello

I recently wrote some code which worked fine on my development machine (Windows, developed in Eclipse using Epic plugin, Perl v5.10.0) but failed (in production, of course) on a Solaris box, Perl v5.8.8. There are various reasons the code wasn't tested prior to production in an as-live scenario ...

I'd like to understand why this failed so I don't make the same (or similar) mistake in future.

I wrote:
my $self->{_dbh} = $dbh; $self->{_sth} = $sth; bless $self, "xxx"; return $self;
On the Solaris box this failed with: Can't use an undefined value as a HASH reference On Windows ... not a whimper. I am using strict and warnings and had run the code through perlcritic (-3).

I resolved this by ...

my $self = {}; ... $self->{_dbh} = $dbh; $self->{_sth} = $sth; bless $self, "xxx"; return $self;

I'm new to Perl but not programming & I get the idea of the error message but I don't understand why it should work on one platform and not the other.

Is it a platform issue? And if so, where can I do some reading on cross platform issues (& how to avoid them)?

Is it a version of Perl issue?

And is my solution acceptable or have I done something bad/wrong here too?

Replies are listed 'Best First'.
Re: Windows/Solaris Difference
by almut (Canon) on Oct 29, 2009 at 00:13 UTC

    It's a Perl version difference. 5.8.8 complains, 5.10.0 doesn't and autovivifies the $self hashref  (just tried both versions on the same platform).

      Fab - thank you for such a super quick reply.

      I'll put 5.8.8 on my Windows box straight away!

Re: Windows/Solaris Difference
by ikegami (Patriarch) on Oct 29, 2009 at 00:48 UTC

    I'd stay away from that syntax since it looks like $self->{_dbh} is the argument of my while it's really just $self.

    my $self->{_dbh} = $dbh;
    means
    (my $self)->{_dbh} = $dbh;

    but that's not what people see.

Re: Windows/Solaris Difference
by aufflick (Deacon) on Oct 29, 2009 at 02:42 UTC
    I program Perl on Solaris, Linux, Windows and MacOS. Here's my simple suggestions:

    You should test on the same OS/Perl version before you release to production.

    If you *really* can't beg/steal/borrow a Solaris login to do that, you need to be using the same version of Perl, that way you're bug for bug compatible, on the same flavour of OS. There are far fewer differences between Perl on Solaris and any other Unix than with windows. Forking and signals, for example, are completely different. If you *really* can't get a server login, you could setup a VMWare virtual machine running Linux on your Windows PC, and with the same version of perl. That gets you a lot closer to your production environment.

    If you stick with developing on Windows, and deploying to Solaris - even worse with different perl versions - you're going to keep having production release issues.

      I did point out there were various reasons for not doing so in this case because I didn't want a lecture on the 'right' way to do stuff. :)

      Yes, in an ideal world the work would have been tested on an as live full volume environment by an independent third party (not the developer) with a full suite of regression tests.

      But there you go!

        I know you said there were various reasons, and I wanted to point out that in my experience the pain of arguing/battling against those reasons is lesser than the pain of continually breaking production.

        Whoever manages the risk in your company could be a good person to get in the loop if you continue to get refusals of either an account or a brand new box for testing.

        I also suggested free ways of achieving an in between result using VMWare that requires only installation approval--if that is an issue I refer to the previous paragraph.

        There you go ;)

      Sun offers a free release of Solaris, and they also have a LiveCD version if you don't want to install it on dedicated h/w: http://www.opensolaris.com/