On 2005-02-18 Mark Wheeler wrote:
>Ok... I made the changes, but still no luck. Here is the script as it
>is, now.
>
>------------------------------------------
>test.cgi
>------------------------------------------
>
>#!/usr/bin/perl -w
>
>use strict;
>
>our @list;
>require 'variables.conf';
>
>foreach (@list) {
>print;
>}
>
>exit;
>
>-------------------------------------------
>variables.conf
>-------------------------------------------
>
>$list[0] = '0';
>$list[1] = '1';
>$list[2] = '2';
>$list[3] = '3';
>$list[4] = '4';
>
>1;
>
>-------------------------------------------------------------------
>
>What am I missing here? Thanks for your help.
That works here. What errors or warnings are you getting? Did you get
rid of the "my @list;" declaration in the require()ed file
(variables.conf)? Permissions OK?
If you're running an earlier version of Perl, instead of
our @list;
write this:
use vars qw/@list/;
before the require() statement.
In the bigger picture, yes, storing Perl code and data structures in
separate files is a widespread practice, rightly so as part of Perl's
easy extensibility.
For a learning path that gives the most solid foundation to this
practice, consider starting now with always running your scripts in
taint mode. What you read in from external files is not secure in many
situations, especially networks -- e.g., the Internet.
Some common script operations, such as open()ing a file with a path
stored in an external config file, could cause severe security issues.
If you incorporate the simple steps required to untaint external data
from the beginning, your programs will more strongly handle increased
complexity and public exposure.
And you will avoid the stress of combing back through a program you need
to make secure, trying to find the elusive points where the -T switch
tenaciously challenges you, an enterprise in which you may risk losing
your appreciation of logically organized electron flows.
HTH
- Bruce
__bruce__van_allen__santa_cruz__ca__
