Variables in external file

> Hi,
>
[quoted text clipped - 21 lines]
>
> my @list;

I remember how my works in blocks, but I'm having trouble remembering
how my works in files.

And I'm having trouble remembering what to do when you actually _want_
a declaration to have global effect. Where're my books?

> $list[0] = '1';
> $list[1] = '2';
[quoted text clipped - 10 lines]
>
> Mark

Reply to this Message

> Just a quick question. Is it possible to have a bunch of variables in
> a separate file and then require that file in the script file? Let me
[quoted text clipped - 8 lines]
> When I try the above script, I get an error - "Global variable @list
> needs to be defined". What am I doing wrong, or is this even possible?

The scope of my @list is the file where it's declared. From 'perldoc -f
my':

A "my" declares the listed variables to be local
(lexically) to
the enclosing block, file, or "eval". If more than one
value
is listed, the list must be placed in parentheses.

You'll need to declare the variable in the script ('our', not 'my'),
before you require variables.conf

Neil

Reply to this Message

Mark Wheeler - 18 Feb 2005 18:05 GMT

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.

Mark

> Just a quick question. Is it possible to have a bunch of variables in
> a separate file and then require that file in the script file? Let me
[quoted text clipped - 8 lines]
> When I try the above script, I get an error - "Global variable @list
> needs to be defined". What am I doing wrong, or is this even possible?

The scope of my @list is the file where it's declared. From 'perldoc -f
my':

A "my" declares the listed variables to be local
(lexically) to
the enclosing block, file, or "eval". If more than one
value
is listed, the list must be placed in parentheses.

You'll need to declare the variable in the script ('our', not 'my'),
before you require variables.conf

Neil

Reply to this Message

John Delacour - 18 Feb 2005 18:22 GMT

>You'll need to declare the variable in the script ('our', not 'my'),
>before you require variables.conf

I don't think it needs to be before;

for (our @list) { print }

will do the trick.

JD

Reply to this Message

Bruce Van Allen - 18 Feb 2005 18:39 GMT

On 2005-02-18 Mark Wheeler wrote:

>Ok... I made the changes, but still no luck. Here is the script as it
>is, now.
[quoted text clipped - 31 lines]
>
>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__

Reply to this Message

Mark Wheeler - 18 Feb 2005 19:24 GMT

Hi,

Well, I checked the line endings. They are unix. It must be
permissions, because the syntax check came up good, and the error is a
500. I've set both to 755. Perl version is 5.8.1 (standard install). I
tried the "use vars qw/@list/;", but that didn't seem to do the trick
either. I know this should be simple, but I'm not sure what the problem
is.

Mark

On 2005-02-18 Mark Wheeler wrote:

> Ok... I made the changes, but still no luck. Here is the script as it
> is, now.
[quoted text clipped - 31 lines]
>
> 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__

Reply to this Message

Wren Argetlahm - 19 Feb 2005 07:51 GMT

> And you will avoid the stress of combing back
> through a program you need
[quoted text clipped - 4 lines]
> your appreciation of logically organized electron
> flows.

Which reminds me... I've been using the #!/usr/bin/env
perl shebang for easier distribution, but env doesn't
like switches. Is there a way to set taint mode via
`use` or the like (ala use warnings; for -w). I can't
seem to locate anything in the manuals other than the
-T flag.

Live well,
~wren

Reply to this Message

Ken Williams - 19 Feb 2005 17:05 GMT

On Feb 19, 2005, at 1:51 AM, wren argetlahm wrote:

> Which reminds me... I've been using the #!/usr/bin/env
> perl shebang for easier distribution, but env doesn't
> like switches. Is there a way to set taint mode via
> `use` or the like (ala use warnings; for -w).

No. By definition, any switch in the script itself would be too late
to set taint mode. Even a '-T' in the shebang line doesn't work if the
script is invoked as "perl foo.pl" instead of "./foo.pl". In that case
it'll just die with the error 'Too late for "-T" option'. See 'man
perldiag'.

-Ken

Reply to this Message

Peter N Lewis - 21 Feb 2005 02:34 GMT

>Which reminds me... I've been using the #!/usr/bin/env
>perl shebang for easier distribution, but env doesn't
>like switches. Is there a way to set taint mode via
>`use` or the like (ala use warnings; for -w). I can't
>seem to locate anything in the manuals other than the
>-T flag.

Correct me if I'm wrong, but the primary reason for using

#!/usr/bin/env perl

is to avoid hardcoding the path to perl. The #! requires an absolute
path, and so if you use #!/usr/bin/perl, you wont work if the
customer is using /usr/local/bin/perl.

On the other hand, Taint mode's purpose is to ensure that your
program cannot do anything nefarious due to user input.

In this case, the user's PATH environment variable would control
which perl you executed, thus rendering all actions suspect.
Generally the first thing a Taint mode program would do is clear the
PATH environment variable to '/bin:/sbin' or the like.

Thus any attempt to use both "/usr/bin/env perl" and taint mode is
fraught with danger.

Regardless, the only place you can use the -T switch is on the
command line unless the script is executed directly in which case the
#! line must be an absolute path to perl.

I have some vague memories of some sort of hack to do something along
the lines of:

#!/bin/sh
perl -T $0 (or whatever the variable is for this script path).

with some magic to hide the perl command from the perl interpreter.
But my memory is insufficient to the task and this would still leave
you susceptible to the user's PATH which you may want to support but
which is quite dangerous to combine with Taint mode.

Enjoy,
Peter.

Signature

I was away from Feb 12 - Feb 19, sorry for any email delays.
<http://www.stairways.com/> <http://download.stairways.com/>

Reply to this Message

>Is it possible to have a bunch of variables in a separate file
>and then require that file in the script file?

Possible, yes. Advisable, no. I tend to use YAML (www.yaml.org)
for this sort of thing, as:

# some_data.yml

List:
- 1
- 2
- 3
- 4
- 5

Then, after loading the file, I access the data as:

foreach $item (@{ $r->{List} }) {
print $item;
}

YAML is easy to read and edit, maps well to Perl data structures,
is language-independent, loads safely, etc.

-r

Signature

email: rdm@cfcl.com; phone: +1 650-873-7841
http://www.cfcl.com - Canta Forda Computer Laboratory
http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc.
http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series

Reply to this Message

Mark Wheeler - 28 Feb 2005 08:36 GMT

Hi all,

Thanks for all you input. I'm mulling it all over to decide what works
best for me. That's the beauty of it all - there's always more than one
way to get what you want. Thanks again.

Mark

At 8:39 AM -0800 2/18/05, Mark Wheeler wrote:

> Is it possible to have a bunch of variables in a separate file
> and then require that file in the script file?

Possible, yes. Advisable, no. I tend to use YAML (www.yaml.org)
for this sort of thing, as:

# some_data.yml

List:
- 1
- 2
- 3
- 4
- 5

Then, after loading the file, I access the data as:

foreach $item (@{ $r->{List} }) {
print $item;
}

YAML is easy to read and edit, maps well to Perl data structures,
is language-independent, loads safely, etc.

-r

Signature

email: rdm@cfcl.com; phone: +1 650-873-7841
http://www.cfcl.com - Canta Forda Computer Laboratory
http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc.
http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series

Reply to this Message

> Hi,
>
> Just a quick question. Is it possible to have a bunch of variables in
> a separate file and then require that file in the script file?

It's generally not a wise choice. Better to use something like
Data::Dumper to write the data to a file, then load it back in the way
the Data::Dumper manpage describes. Or YAML (as Rich pointed out), or
Storable, etc.

If you don't like that approach, consider at *least* wrapping it in a
subroutine:

----------------------------------------------------------
Script file
----------------------------------------------------------

#!/usr/local/bin/perl -w
use strict;
require variables.conf

print "Content-type: text/html\n\n";
foreach (&list) {
print;
}

exit;

---------------------------------------------------------
variables.conf
---------------------------------------------------------

my @list;

$list[0] = '1';
$list[1] = '2';
$list[2] = '3';
$list[3] = '4';
$list[4] = '5';

sub list { @list }

1;
---------------------------------------------------------

Reply to this Message

Mac Forum / Programming / Perl / February 2005

Variables in external file