in reply to Problems with using strict

The way in which you are loading module.pm is most likely deprecated. Besides, you don't even show us what that module is/does. I recommond you ditch that code and start over with something like: 
use strict;
use warnings;

use CGI::Pretty qw(:standard);
use Geography::Countries;

print header,
   start_html('Country'),
   scalar country('AF'),
   end_html,
;

[download]
You more than likely have CGI installed, but you more than likely do not have Geography::Countries already installed. Grab it. Use the CPAN. Make your life easier. :)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Replies are listed 'Best First'.
Re: (jeffa) Re: Problems with using strict
by kiat (Vicar) on Apr 19, 2003 at 14:41 UTC
    Thanks, jeffa! What is the correct way to include a module and how do I fix my code above assuming I need to include a self-written module?
[reply]
      No problem. I like to first add the path where the module lies to @INC rather than assume the module will always be in the same directory as the executing script. Something like: 
      use lib '/path/to/my/module';
use module;

      [download]
      require is not deprecated, but i use use 99.99% of the time. Follow those links or read about those two pragmas with: 
      
perldoc -f use
perldoc -f require
      If you want to install Geography::Countries, you should read A Guide to Installing Modules.

      jeffa

      L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
[reply]
[d/l]

      A couple of ways...

      • Put the module in the directory where the script runs
      • Add use lib '/path/to/my/modules' before using any of your modules
      • Update: Set the environment variable PERLLIB or PERL5LIB to the location of your modules
      90% of every Perl application is already written. ⇒
      dragonchild
[reply]
[d/l]

        These are indeed three ways to adjust where modules are found. Some extra notes:

        • Don't expect '.' to be in @INC if it may be run by root; perl reigns in that behavior for uid==0.
        • I really don't care much for use lib '/hard/wired/path' especially in a multiple-platfom corporate deployment environment. There is no '\\winsvr\perl\extensions\lib' on Solaris and no '/corp/home/perl' on Windows, for example. I made a corporate-specific setup module which (among many other things) performed the equivalent @INC adjustment but only after doing a few heuristic checks to decide the appropriate path. Then any corporate-specific script could just 'use DynaCorp;' to reap the benefits.
        • Let the system administrators setenv PERLLIB to appropriate site-wide values. Don't adjust or assume the value of PERLLIB on behalf of a single script or application, it really complicates installation of that script into new environments. Imagine trying to tell a co-worker that this tool will help them, but neither you nor they have permissions to adjust PERLLIB without a hackish wrapper BAT file or .sh script.

        --
        [ e d @ h a l l e y . c c ]

[reply]

In Section Seekers of Perl Wisdom