Wiggins d'Anconia wrote on 30.04.2004:
>Jan Eden wrote:
>>Hi all,
>>
>>I wrote a little form mail script and start by setting the
>>environment variables like this:
>>
>>BEGIN { $ENV{PATH} = "/usr/sbin"; delete @ENV{ qw( IFS CDPATH ENV
>>BASH_ENV) };
>>}
>>
>>Now the actual directory (.) is obviously not searched anymore,
>>since
>>
>>my $page_head = eval do('page_head.pl');
>>
>>returns an empty $page_head while
>>
>>my $page_head = eval do('./page_head.pl');
>>
>>fills it with the appropriate content.
>>
>>Commenting the BEGIN block above and printing $ENV{PATH} gives me:
>>
>>/bin:/sbin:/usr/bin:/usr/sbin:/usr/libexec:/System/Library/
>>/CoreServices
>>
>>I cannot see the current working directory in that list (but I admit
>>that I am not used to environment variables at all).
>>
>>Can someone tell me how to restrict $ENV{PATH} but keep the script's
>>ability to see something in its own directory?
>>
>
>The current working directory and the script's own directory are
>different things.
>
Yes. I meant the script's own directory.
>perldoc Cwd perldoc FindBin
>
>Does,
>
>use FindBin qw($Bin);
>
>my $page_head = eval do($Bin . '/page_head.pl');
>
>Get you where you are going?
>
Not exactly. Let me explain.
>Out of curiousity what's with the 'eval do' stuff? What are you
>really trying to do?
The 'eval do' combination is a neat trick Rob Dixon suggested: I have a piece of html
code containing some perl variables in page_head.pl / page_foot.pl.
To evaluate the content of a file, 'do' is the easiest way. But code evaluated with
'do' does not see variables in the enclosing scope. So Rob suggested the following
construction:
q{ qq{ #code with variables here# } };
When 'do' evaluates this, it returns
qq{ #code with variables here# }
If I apply this as an argument to 'eval', the variables are interploated in the
context of the current script. Neat.
But now I decided to use a more Perl style solution, namely building a simple module
which contains a subroutine 'headfoot'. This subroutine should take the variables
occurring in the page head/foot as arguments and return the page head/foot with the
values inserted, like
sub headfoot {
my ($id, $mode, $mother_title) = shift;
my $page_head = "html html $mode html html $mother_title html $id";
return $page_head;
}
Since I do not have access to the Perl installed on my server, I can only use modules
in the directory I store my own scripts in. When not manipulating the environment
variables, this is not a problem.
But when setting $ENV{PATH} like above, the script's own directory is not searched (as
the failure of do('page_head.pl') shows). When using a module, though, I cannot say
use ./Module
as I can do with 'do' (as in do('./page_head.pl')). So the upshot is: I want to set
$ENV{PATH} to make the form mail script more secure, but I want to include the
script's own directory (in a principled way, not as an absolute path on my machine) in
$ENV{PATH}.
$ENV{PATH} = ".:/usr/sbin";
did not do what I want.
Sorry for the extensive post.
Thanks,
Jan
--
Common sense is what tells you that the world is flat.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
