You're asking the wrong question. strict.pm was included in Perl 5.005. If your installation doesn't have it then your installation is badly broken and can't be trusted. I recommend getting Perl reinstalled on that server as a matter of some urgency. You shouldn't be trying to work around its problems.

If you can't get Perl reinstalled then I recommend getting a new hosting company, sysadmin or job as appropriate.

I'm currently on contract with the sysadmin group at this random large corporation, so I suppose I'm in as good of a position as anyone to try to get it fixed. I expect the attempt to fail, thanks to their paranoid change management policies, but, if it does fail, my contract runs out in a month, so I'll be getting a new job anyhow.

Well perl 5.00502 as that message indicates the version in question is certainly did have strict I have a horrible feeling that you are going to find something even worse wrong with the perl installation even if you fix that, I suspect that they probably have just copied the perl binary without the libraries or just a few of them.

Of course you could do something like:

BEGIN
{
   eval
   {
      require strict;
   };
   strict->import() unless $@;
}
[download]

/J\

Your suspicion looks quite likely to be correct... After discovering that the host in question is also missing Sys::Hostname, I took a look at @INC and none of the directories it references (except '.', of course) even exist.

sigh.

That's a very broken installation of perl. Perl 5.5 should have strict.pm installed with it. That's a fault the admin should correct.

Failing administrative sympathy, you can move a copy of strict.pm into your own space and tell perl to look there with the PERL5LIB environment variable.

Dave.

Just out of curiousity, what gave it away as HPUX? Are they the only ones who put it in /opt/.../PA-RISC?

The most common OS that runs on PA-RISC is HP-UX. See the Wikipedia PA-Risc family entry for more.

eval 'use strict';
if ($@) {  # If it cannot 'use strict' then it will put the error in $
+@
  print "Cannot 'use strict', it appears to be missing\n";
}
[download]

Update: Put the {} for the eval command in the wrong place... Just taking them out altogether and removing it from the BEGIN block. At least I learned something today.

While that trick can be used for detecting if strict exists, it won't turn strict on.

            strict ends here
                   |
                   |
BEGIN {            v
   eval 'use strict';
   warn("Cannot 'use strict', it appears to be missing\n") if $@;
}
[download]

On the other hand, the following works (and doesn't use eval EXPR):

BEGIN {           
   eval { require strict };
   if ($@) {
      warn("Cannot 'use strict', it appears to be missing\n");
   } else {
      strict->import();
   }
}
[download]

Seeing how strict is lexically scoped using it inside of an eval inside of a BEGIN block's scope isn't really going to do the rest of one's code much good . . .

Well you might say that:

BEGIN
{
   eval
   {
      require strict;
   };
   strict->import() unless $@;
}
                                                                      
+          
$foo = 1;
[download]

Gives rise to:

Global symbol "$foo" requires explicit package name at hdhd line 10.
Execution of hdhd aborted due to compilation errors.
[download]

So no it does work. Update: but of course the string eval is different.

/J\

The problem with that is that the following script compiles without complaints (even when strict is available) and prints "5".

sub BEGIN {
  { eval 'use strict' }
}
$not_declared = 5;
print $not_declared, "\n";
[download]

"use strict" is always local for the surrounding block, so you cannot put it into eval or BEGIN.