[30053] in Perl-Users-Digest
Perl-Users Digest, Issue: 1296 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Feb 21 14:09:52 2008
Date: Thu, 21 Feb 2008 11:09:17 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 21 Feb 2008 Volume: 11 Number: 1296
Today's topics:
Re: How do you track down the way to POST a form ? <telemach@go2.pl>
How to call a TCL script from within a perl scrip/progr cyrusgreats@gmail.com
Re: How to call a TCL script from within a perl scrip/p <glex_no-spam@qwest-spam-no.invalid>
Re: how to retrieve info <glex_no-spam@qwest-spam-no.invalid>
Re: how to retrieve info <michaelgang@gmail.com>
Openning a File <matthew.menard@navy.mil>
Re: Openning a File <michaelgang@gmail.com>
Re: Openning a File <glex_no-spam@qwest-spam-no.invalid>
Re: Openning a File <matthew.menard@navy.mil>
Re: Openning a File <thepoet_nospam@arcor.de>
Re: perl data structure <michaelgang@gmail.com>
Re: Regular Expression to Replace UPPER Case Text with <cartercc@gmail.com>
Re: setting %ENV in a module <pgodfrin@gmail.com>
Re: setting %ENV in a module <pgodfrin@gmail.com>
Re: setting %ENV in a module <jimsgibson@gmail.com>
Re: setting %ENV in a module <joost@zeekat.nl>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 21 Feb 2008 01:25:11 -0800 (PST)
From: Telemach <telemach@go2.pl>
Subject: Re: How do you track down the way to POST a form ?
Message-Id: <d0fc8e73-97a8-472f-b06e-0d83f238364a@72g2000hsu.googlegroups.com>
> Get the Firebug and Web Developer Toolbar extensions for Firefox. =A0They
> will let you track everything you need, both the POST content and the
> visual layout of the page (including hidden elements and form fields).
Thanks, I will try. Right now I've managed to make use of
LiveHTTPheaders to browse the POST content.
- Telemach -
------------------------------
Date: Thu, 21 Feb 2008 09:33:24 -0800 (PST)
From: cyrusgreats@gmail.com
Subject: How to call a TCL script from within a perl scrip/program
Message-Id: <38fd76a6-8cf4-48f7-ae9a-7cf82ed517de@e6g2000prf.googlegroups.com>
I have a need to call a TCL script from within a perl scrip/program.
What is the best way to do this. Has anyone done this before. Can
anyone recommend a module for this.
Thanks in advance..
------------------------------
Date: Thu, 21 Feb 2008 11:52:08 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: How to call a TCL script from within a perl scrip/program
Message-Id: <47bdba49$0$504$815e3792@news.qwest.net>
cyrusgreats@gmail.com wrote:
> I have a need to call a TCL script from within a perl scrip/program.
> What is the best way to do this. Has anyone done this before. Can
> anyone recommend a module for this.
No. No one has ever even thought of calling another script/program
from within a perl program, you're the first. :-)
You do it the same way you'd execute any other non-perl program.
perldoc -f system
perldoc -q "Why can't I get the output of a command with system"
------------------------------
Date: Thu, 21 Feb 2008 10:29:55 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: how to retrieve info
Message-Id: <47bda703$0$10306$815e3792@news.qwest.net>
Rose wrote:
> i have hundreds of files to submit to
>
> http://propka.ki.ku.dk/~drogers/
>
> for analysis. the inputs are some 4-letter code, e.g. 1a00, 1brs, 2bti,
> 3bmn, ...
>
> How can I tell perl to submit the values and retrieve the results under a
> Linux platform?
>
>
Is this the first place you go for help? Try reading through
some documentation, asking co-workers, searching the Internet,
searching CPAN, or make some attempt at finding a solution on
your own.
Searching the Internet on "perl http submit" returned many
helpful places to start. Here are a few more:
perldoc lwpcook
LWP::Simple
WWW::Mechanize
lwp-request
------------------------------
Date: Thu, 21 Feb 2008 08:32:06 -0800 (PST)
From: david <michaelgang@gmail.com>
Subject: Re: how to retrieve info
Message-Id: <9869a924-db61-4476-a465-c72827859706@n77g2000hse.googlegroups.com>
On Feb 21, 9:09 am, "Rose" <r...@russ.org> wrote:
> i have hundreds of files to submit to
>
> http://propka.ki.ku.dk/~drogers/
>
> for analysis. the inputs are some 4-letter code, e.g. 1a00, 1brs, 2bti,
> 3bmn, ...
>
> How can I tell perl to submit the values and retrieve the results under a
> Linux platform?
Hi,
Did you try the LWP module from CPAN ?
Best regards,
David
------------------------------
Date: Thu, 21 Feb 2008 06:46:22 -0800 (PST)
From: MattM <matthew.menard@navy.mil>
Subject: Openning a File
Message-Id: <7346d6f6-7f76-477b-bf01-f1eb0a57d829@j28g2000hsj.googlegroups.com>
This should be fairly straightforward, but I'm having trouble openning
a file. I'm modifying a current perl script that seemed to run fine.
I open a file for input, parse it, make some changes to it, create
another file, and write the changes to the new file. I wanted to open
up another file for input, but when I do, it seems to be adding spaces
between each character in the line as its read in. On of the lines of
the file looks something like:
ZZZ223 FP2115
the columns are seperated by a tab. What I get when I run the simple
file openning code is:
Z Z Z 2 2 3 F P 2 1 1 5
I'm trying to put these into a hash table for quick access later in
the program. The code I'm using is pretty simple. It looks like:
open MYFILE,"myfile.txt" or die "Can't open trigger file: $!\n";
while (<MYFILE>) {
chomp;
print STDOUT $_ . "\n";
$lineIn = $_;
($parm,$trigger) = split /\s+/, $lineIn;
$triggers{$parm} .= $trigger;
}
close MYFILE;
But when I run this I get the strange spacing problem. Any Ideas?
Thanks...
------------------------------
Date: Thu, 21 Feb 2008 08:21:59 -0800 (PST)
From: david <michaelgang@gmail.com>
Subject: Re: Openning a File
Message-Id: <41f50546-f067-47b9-8371-1fcc64b1713b@n58g2000hsf.googlegroups.com>
On Feb 21, 4:46 pm, MattM <matthew.men...@navy.mil> wrote:
> This should be fairly straightforward, but I'm having trouble openning
> a file. I'm modifying a current perl script that seemed to run fine.
> I open a file for input, parse it, make some changes to it, create
> another file, and write the changes to the new file. I wanted to open
> up another file for input, but when I do, it seems to be adding spaces
> between each character in the line as its read in. On of the lines of
> the file looks something like:
>
> ZZZ223 FP2115
>
> the columns are seperated by a tab. What I get when I run the simple
> file openning code is:
>
> Z Z Z 2 2 3 F P 2 1 1 5
>
> I'm trying to put these into a hash table for quick access later in
> the program. The code I'm using is pretty simple. It looks like:
>
> open MYFILE,"myfile.txt" or die "Can't open trigger file: $!\n";
>
> while (<MYFILE>) {
>
> chomp;
>
> print STDOUT $_ . "\n";
>
> $lineIn = $_;
>
> ($parm,$trigger) = split /\s+/, $lineIn;
>
> $triggers{$parm} .= $trigger;
>
> }
>
> close MYFILE;
>
> But when I run this I get the strange spacing problem. Any Ideas?
> Thanks...
Hi,
I ran your program on the sample line but did not observe the problem.
Best regards,
Michael
------------------------------
Date: Thu, 21 Feb 2008 10:37:42 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Openning a File
Message-Id: <47bda8d7$0$507$815e3792@news.qwest.net>
MattM wrote:
> This should be fairly straightforward, but I'm having trouble openning
> a file. I'm modifying a current perl script that seemed to run fine.
> I open a file for input, parse it, make some changes to it, create
> another file, and write the changes to the new file. I wanted to open
> up another file for input, but when I do, it seems to be adding spaces
> between each character in the line as its read in. On of the lines of
> the file looks something like:
Instead of 'something like', provide the actual lines.
>
> ZZZ223 FP2115
>
> the columns are seperated by a tab. What I get when I run the simple
> file openning code is:
>
> Z Z Z 2 2 3 F P 2 1 1 5
[...]
Post an actual example that displays the issue. Since we don't have
access to your 'myfile.txt' and you didn't show the code that's
doing something with your hash, there's no way anyone can reproduce
your issue.
e.g.
my $lineIn = 'ZZZ223 FP2115';
my ($parm,$trigger) = split /\s+/, $lineIn;
print "parm=$parm trigger=$trigger\n";
parm=ZZZ223 trigger=FP2115
------------------------------
Date: Thu, 21 Feb 2008 09:23:32 -0800 (PST)
From: MattM <matthew.menard@navy.mil>
Subject: Re: Openning a File
Message-Id: <01259293-6406-4bf2-a8ee-28664690f80d@41g2000hsc.googlegroups.com>
When I tried to create a smaller subset of "myfile.txt" that I copied
from the larger file, the code worked ok. Just for the heck of it, I
opened up the larger file in Hex. My text editor indicated that there
were null characters in between the valid alphanumeric values. When
the editor is allowed to display that larger file, it must
automatically remove the nulls, because it appeared as subsequent
valid alphanumeric values. When I copied some of the values to the
smaller file, it seems to have removed the nulls as well. When I
brought up the smaller file in Hex, it didn't have the nulls between
the alphanumeric values. The process of copying the file removed the
nulls. Not sure why. But anyway, thanks for the input. It made me
dig a little deeper....
J. Gleixner wrote:
> MattM wrote:
> > This should be fairly straightforward, but I'm having trouble openning
> > a file. I'm modifying a current perl script that seemed to run fine.
> > I open a file for input, parse it, make some changes to it, create
> > another file, and write the changes to the new file. I wanted to open
> > up another file for input, but when I do, it seems to be adding spaces
> > between each character in the line as its read in. On of the lines of
> > the file looks something like:
>
> Instead of 'something like', provide the actual lines.
>
> >
> > ZZZ223 FP2115
> >
> > the columns are seperated by a tab. What I get when I run the simple
> > file openning code is:
> >
> > Z Z Z 2 2 3 F P 2 1 1 5
> [...]
>
> Post an actual example that displays the issue. Since we don't have
> access to your 'myfile.txt' and you didn't show the code that's
> doing something with your hash, there's no way anyone can reproduce
> your issue.
>
> e.g.
>
> my $lineIn = 'ZZZ223 FP2115';
> my ($parm,$trigger) = split /\s+/, $lineIn;
> print "parm=$parm trigger=$trigger\n";
>
> parm=ZZZ223 trigger=FP2115
------------------------------
Date: Thu, 21 Feb 2008 19:28:24 +0100
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: Openning a File
Message-Id: <47bdc2c3$0$23012$9b4e6d93@newsspool1.arcor-online.net>
MattM wrote:
> When I tried to create a smaller subset of "myfile.txt" that I copied
> from the larger file, the code worked ok. Just for the heck of it, I
> opened up the larger file in Hex. My text editor indicated that there
> were null characters in between the valid alphanumeric values. When
> the editor is allowed to display that larger file, it must
> automatically remove the nulls, because it appeared as subsequent
> valid alphanumeric values. When I copied some of the values to the
> smaller file, it seems to have removed the nulls as well. When I
> brought up the smaller file in Hex, it didn't have the nulls between
> the alphanumeric values. The process of copying the file removed the
> nulls.
Then welcome to the wonderful word of unicode and the
evil difference between characters and bytes :)
Have a look at "perldoc -f open" and the docs mentioned
there, "perldoc PerlIO" and "perldoc perluniintro".
There's a lot of information and examples on the topic
of using single- and multibyte encodings in Perl.
-Chris
[And please, try not to top-post. Putting the answer below
the cited text makes it really easier to follow a conversation.]
------------------------------
Date: Thu, 21 Feb 2008 08:52:20 -0800 (PST)
From: david <michaelgang@gmail.com>
Subject: Re: perl data structure
Message-Id: <148f0ed2-68e9-4933-bc5c-f85fa684bf89@62g2000hsn.googlegroups.com>
On Feb 19, 7:15 pm, BH <Benson....@googlemail.com> wrote:
> Hi,
>
> I am reading in an comma separator file,
>
> line 1: Field 1, field 2, field 3.., field n
> line 2: Field 1, field 2, field 3.., field n
>
> I would like to create a data structure to representing the whole
> file.
>
> What is an efficient and easy way to store the above such that, for a
> given value for field i, I can extract an array of values for field j,
> where 1<=i,j<=n? It's a bit like asking what the best way to store a
> spreadsheet is.
>
> Hash of anonymous arrays? How will the syntax be?
>
> Thanks in advance.
>
> Regards,
>
> BH
Hi,
Lokk at Data::Table,
Best regards,
David
------------------------------
Date: Thu, 21 Feb 2008 04:23:48 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: Regular Expression to Replace UPPER Case Text with lower case text
Message-Id: <83342394-91d2-4e35-93fd-3c33f298ab9c@q70g2000hsb.googlegroups.com>
On Feb 20, 2:46 pm, Charlton Wilbur <cwil...@chromatico.net> wrote:
> You seem to think that "he's an idiot" can be countered by "but he's
> not a programmer or a software engineer." Technical management is
> equal parts technical knowledge and management knowledge, which is why
> it's so often done poorly.
Not at all. 'Idiot' means someone with a very, very low IQ, a retarded
person. 'Ignorant' simply means lacking information. It shouldn't
surprise you that someone who spent all his career on the business
side lacks knowledge and experience on the technical side.
> You also seem to think that "he's an idiot" can be countered by "he's
> done well in his career." Examples of successful idiots abound;
> you've even offered a number of anecdotes yourself.
Again, no. A successful person isn't an idiot. He may do idiotic
things, he may be ignorant in certain knowledge domains, but he isn't
an idiot.
> You do a very poor job of evangelizing for Perl if you're advising
> people that (a) they'll be laughed at for using it and (b) it's best
> avoided, as it's 1980s technology.
(a) In some circumstances, you ~will~ be laughed at for using
particular technologies, including Perl. This is simply a statement of
fact. (b) Do you not recognize sarcasm? At least Tad recognized this
as an attempt at humor.
Part of this relates to some very recent personal experience. Since
January 1, I have been told the following:
(a) The place to set the budget and the schedule is in the scoping
phase of the project. ('Scoping' is where you determine whether you
have a problem that can be addressed by technology.)
(b) You don't involve technical people in the analysis and design
phases of a project because they will get you bogged down with
discussions involving technical solutions, and analysis and design
does not consider technologies.
(c) You set the requirements, design the project, implement the code,
and deliver it. If you have to backtrack, i.e., iterate, it means you
failed to successfully complete a prior stage.
(d) You debug and correct an application just before delivery. That
way you can catch all the errors at one time and you don't need to
waste any time in previous stages testing for and correcting errors.
Yeah, I know. But you really can't call people four or five levels
above you, and who control the finances and can kill your project,
idiots. Even if they have idiotic ideas. As far as I can ten, our
schools are churning out MBAs with their heads filled with nonsense
like the above. And to be totally candid, it appears that some portion
of their (bad) attitude toward technology is earned, at least to the
extent that engineers and developers ignore the business side.
Like ... how do we turn this into money?
This has gotten way off thread. I won't be replying. You can have the
last word on this topic.
CC
------------------------------
Date: Thu, 21 Feb 2008 05:58:19 -0800 (PST)
From: pgodfrin <pgodfrin@gmail.com>
Subject: Re: setting %ENV in a module
Message-Id: <cb07b072-72a9-41dc-932b-f0023c8882d2@e10g2000prf.googlegroups.com>
On Feb 21, 2:02 am, Joost Diepenmaat <jo...@zeekat.nl> wrote:
> pgodfrin <pgodf...@gmail.com> writes:
> > I'd like to put that subroutine in a module so that I can use that
> > subroutine wherever I want to. I having problems with scoping - seems
> > the module subroutine sets the environment but then loses when control
> > is returned to the calling program. This part is hard.
>
> I'm not sure if this applies to your problem, but tou may be unaware
> that on most operating systems it's impossible to set the environment
> for anything other than the "current process" (and any child processes
> will then inherit the parent's environment).
>
> In other words, if program A fork()s program B, and program B
> changes its %ENV, program A will not see those changes. Neither will
> program B see any changes in program A's environment made after B is
> forked off.
>
> --
> Joost Diepenmaat | blog:http://joost.zeekat.nl/| work:http://zeekat.nl/
Yes I'm aware of this - I think this is a scoping issue. So program A
loads the modules, and then calls it to set the environment values. I
only care for the variables set during that process, and any other
from the calling program. However, certain variables get set and
others are not set exactly right....
I'll send some example code shortly...
pg
------------------------------
Date: Thu, 21 Feb 2008 09:15:17 -0800 (PST)
From: pgodfrin <pgodfrin@gmail.com>
Subject: Re: setting %ENV in a module
Message-Id: <0d055ad0-b659-4ae8-b907-01e482fcef0d@i12g2000prf.googlegroups.com>
...snip...
>
> Yes I'm aware of this - I think this is a scoping issue. So program A
> loads the modules, and then calls it to set the environment values. I
> only care for the variables set during that process, and any other
> from the calling program. However, certain variables get set and
> others are not set exactly right....
>
> I'll send some example code shortly...
> pg
Well - here's the scoop. I believe this is not necessarily a scoping
issue, but one of understanding how perl interprets environment
variables. (or maybe how I interpret how... <grin>). It appears that
if one tries to set $ENV{VARNAME}="$ENV-VAR" (with or without quotes)
then the resulting hash value is the literal $ENV-VAR - perl is not
evaluating the scalar variable. (as opposed to use Env qw(VAR-NAME)
which permits using $VAR-NAME as a scalar variable in the subsequent
code).
I'm a little stumped as to why.
the input file (I'd like to be compatible with unix export statements.
I strip that out later)
export TMPTEST=/tmp
export TMPTOO=$TMPTEST
The simplified module:
package MymodSimp;
use Env;
Env::import;
my(@rvars,$l,$e,$v);
open RVARS,"/home/pgodfrin/perl/et/etfile" ;
@rvars=<RVARS>; close RVARS;
foreach (@rvars)
{
if (!/(^export)(\s+)\w+=/) { next;} # skips garbage
($l,$e,$v) = (/^(export\s+)(\w+)=(.+)/);
$ENV{$e}="$v";
}
$ENV{TMPTREE}='myliteral';
1;
The calling program:
[pgodfrin:~/perl/et]> cat envtest
#!/usr/bin/perl
use warnings;
no warnings 'once';
use Env;
Env::import;
use MymodSimp ;
$ENV{TMPFOUR}="$TMPTOO";
$ENV{TMPFIVE}=$ENV{TMPTEST};
print "TMPTEST: $ENV{TMPTEST}\n";
print "TMPTOO: $ENV{TMPTOO}\n";
print "TMPTREE: $ENV{TMPTREE}\n";
print "TMPFOUR: $ENV{TMPFOUR}\n";
print "TMPFIVE: $ENV{TMPFIVE}\n";
chdir("$TMPTEST") or die "Can't change dir to $TMPTEST\n";
print "Change to dir $TMPTEST:"; system("pwd"); print "\n";
chdir("$TMPTOO") or die "Can't change dir to $TMPTOO\n";
print "Change to dir $TMPTOO:"; system("pwd"); print "\n";
chdir("$TMPFIVE") or die "Can't change dir to $TMPFIVE\n";
print "Change to dir $TMPFIVE:"; system("pwd"); print "\n";
exit;
The execution.
[pgodfrin:~/perl/et]> envtest
TMPTEST: /tmp
TMPTOO: $TMPTEST
TMPTREE: myliteral
TMPFOUR: $TMPTEST
TMPFIVE: /tmp
Change to dir /tmp:/tmp
Can't change dir to $TMPTEST
So - setting $ENV{TMPTOO}="$TMPTEST" doesn't evaluate the variable.
I was hoping to be able to have a perl program that uses environment
variables via the use Env qw(yada-yada) construct, but also be able to
load the env vars from a file in the event the same perl program is
called via the crontab. There is a workaround for the crontab thing:
(. varfile; myperlpgm) - this will first source the varfile and any
env vars defined there will be available to myperlpgm via use Env
qw(yada-yada), but that doesn't seem very elegant. Another work around
is to create a wrapper for any perl program that is executed in the
crontab: 22 13 * * * run-job - where run-job is either a shell script
or a calling perl program which set's the variables, but that also
seem inelegant and has it's own set of problems). In any case, that's
the source of my consternation...
regards,
pg
------------------------------
Date: Thu, 21 Feb 2008 10:50:45 -0800
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: setting %ENV in a module
Message-Id: <210220081050458820%jimsgibson@gmail.com>
In article
<0d055ad0-b659-4ae8-b907-01e482fcef0d@i12g2000prf.googlegroups.com>,
pgodfrin <pgodfrin@gmail.com> wrote:
> Well - here's the scoop. I believe this is not necessarily a scoping
> issue, but one of understanding how perl interprets environment
> variables. (or maybe how I interpret how... <grin>). It appears that
> if one tries to set $ENV{VARNAME}="$ENV-VAR" (with or without quotes)
> then the resulting hash value is the literal $ENV-VAR - perl is not
> evaluating the scalar variable. (as opposed to use Env qw(VAR-NAME)
> which permits using $VAR-NAME as a scalar variable in the subsequent
> code).
That is most definitely not true. You are extracting the string
'$TMPTEST' from a string using a regular expression and storing it into
the variable $v. When you assign the value of $v, using the expression
"$v", to the value of the %ENV hash, that string gets stored as is. If
you want to evaluate what $v contains as a Perl expression, then you
should use the eval operator:
$ENV{$e} = eval $v;
See the difference here:
% perl -e '$x=q($y);$y="abc";print $x,"\n";'
$y
% perl -e '$x=q($y);$y="abc";print eval $x,"\n";'
abc
The Env package (I have not used it) ties the values of the members of
%ENV to scalar variables (and arrays if needed), so it will tie
$ENV{TMPTEST} to $TMPTEST, and changing one will change the other.
Perhaps this fact is confusing you. If so, you might be better off not
using Env.pm and sticking to just using %ENV.
>
> I'm a little stumped as to why.
>
> the input file (I'd like to be compatible with unix export statements.
> I strip that out later)
> export TMPTEST=/tmp
> export TMPTOO=$TMPTEST
>
> The simplified module:
> package MymodSimp;
> use Env;
> Env::import;
> my(@rvars,$l,$e,$v);
> open RVARS,"/home/pgodfrin/perl/et/etfile" ;
> @rvars=<RVARS>; close RVARS;
> foreach (@rvars)
> {
> if (!/(^export)(\s+)\w+=/) { next;} # skips garbage
> ($l,$e,$v) = (/^(export\s+)(\w+)=(.+)/);
> $ENV{$e}="$v";
> }
> $ENV{TMPTREE}='myliteral';
> 1;
It is an inefficient use of memory to read a file into an array,
process the lines of that array one-at-a-time, and discard the array.
It is more efficient to process the lines when they are read.
There is no need to use two identical regular expressions to test for a
match and then extract data. Do it in one step.
It is better to use private variables for file handles and use the
three-argument version of open.
There is no need to quote scalar variables.
Therefore:
package MymodSimp;
open my $rvars, '<', "/home/pgodfrin/perl/et/etfile" ;
foreach (<$rvars>)
{
if( /^export\s+(\w+)=(.+)/ ) {
$ENV{$1}=$2;
}
}
$ENV{TMPTREE}='myliteral';
1;
>
> The calling program:
> [pgodfrin:~/perl/et]> cat envtest
> #!/usr/bin/perl
use strict;
> use warnings;
> no warnings 'once';
> use Env;
> Env::import;
> use MymodSimp ;
>
> $ENV{TMPFOUR}="$TMPTOO";
> $ENV{TMPFIVE}=$ENV{TMPTEST};
> print "TMPTEST: $ENV{TMPTEST}\n";
> print "TMPTOO: $ENV{TMPTOO}\n";
> print "TMPTREE: $ENV{TMPTREE}\n";
> print "TMPFOUR: $ENV{TMPFOUR}\n";
> print "TMPFIVE: $ENV{TMPFIVE}\n";
>
> chdir("$TMPTEST") or die "Can't change dir to $TMPTEST\n";
> print "Change to dir $TMPTEST:"; system("pwd"); print "\n";
> chdir("$TMPTOO") or die "Can't change dir to $TMPTOO\n";
> print "Change to dir $TMPTOO:"; system("pwd"); print "\n";
> chdir("$TMPFIVE") or die "Can't change dir to $TMPFIVE\n";
> print "Change to dir $TMPFIVE:"; system("pwd"); print "\n";
>
> exit;
>
> The execution.
> [pgodfrin:~/perl/et]> envtest
> TMPTEST: /tmp
> TMPTOO: $TMPTEST
> TMPTREE: myliteral
> TMPFOUR: $TMPTEST
> TMPFIVE: /tmp
> Change to dir /tmp:/tmp
>
> Can't change dir to $TMPTEST
>
> So - setting $ENV{TMPTOO}="$TMPTEST" doesn't evaluate the variable.
It does, but that is not what you are doing. You are doing
$ENV{TMPTOO} = "$TMPTOO";
where $TMPTOO contains '$TMPTEST'.
--
Jim Gibson
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: Thu, 21 Feb 2008 20:00:23 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: setting %ENV in a module
Message-Id: <87ve4iuoc8.fsf@zeekat.nl>
pgodfrin <pgodfrin@gmail.com> writes:
> the input file (I'd like to be compatible with unix export statements.
> I strip that out later)
> export TMPTEST=/tmp
> export TMPTOO=$TMPTEST
>
> The simplified module:
[ ... ]
> ($l,$e,$v) = (/^(export\s+)(\w+)=(.+)/);
> $ENV{$e}="$v";
This is your problem.
Since you're TMPTOO=$TMPTEST is read from a file it's not
interpolated. You're effectively doing
my $e = 'TMPTOO';
my $v = '$TMPTEST';
$ENV{$e}=$v;
Also note that "$v" only interpolates the value of $v, not any $vars in
the value of $v. This is intentional, since otherwise reading from a
file or assigning strings would interpolate all over the place.
I'd do something like this:
my ($l,$e,$v) = (/^(export\s+)(\w+)=(.+)/);
$v = s/\$(\w+)/$ENV{$1}/eg; #look up $somethings in $ENV
$ENV{$e}=$v;
Note 2: this does not handle quotes in the export statement.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 1296
***************************************
