[22107] in Perl-Users-Digest
Perl-Users Digest, Issue: 4329 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Dec 31 21:31:22 2002
Date: Tue, 31 Dec 2002 18:30:30 -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 Tue, 31 Dec 2002 Volume: 10 Number: 4329
Today's topics:
Re: while and eof <news@roth.lu>
Re: while and eof (Tad McClellan)
Re: while and eof <goldbb2@earthlink.net>
Re: while and eof (Joe Smith)
Re: Wierd loop/chdir behavior (Steve Walker)
Re: Wierd loop/chdir behavior (Steve Walker)
Re: Wierd loop/chdir behavior <bongie@gmx.net>
Re: Wierd loop/chdir behavior <goldbb2@earthlink.net>
Yet Another Question About: "my" and scope of vars... <bik.mido@tiscalinet.it>
Re: Yet Another Question About: "my" and scope of vars <koos_pol@NO.nl.JUNK.compuware.MAIL.com>
Re: Yet Another Question About: "my" and scope of vars (Anno Siegel)
Re: Yet Another Question About: "my" and scope of vars <thomas-usenet@arcor.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 30 Dec 2002 15:24:24 +0100
From: "J.M.Roth" <news@roth.lu>
Subject: Re: while and eof
Message-Id: <3e105719_1@news.vo.lu>
I agree this looks somewhat cleaner but there is something I can't get to
work using the new version
I've marked a line below with #1. I can't make it to the else if, even if
($y==$year and $m==$month) is false... ?
In fact the debugger tells me it quits right at the if, i.e. after the if
line there is immediately $is_first_file=0 ...
I also changed the label somewhat, I don't need to jump to the next file if
the elseif is met.
If the elseif is met, I either
1. have all the results I need (@result) or
2. it is at the very beginning and there are no results ( $is_first_file and
$.==1 and Delta_Days($year,$month,$lastday, $y,$m,$d)>0 )
By the way, what was the "=>" you were using in the first Delta_Days??
Also the tai=line=~regexp was bogus, I changed it back to $1.
Regards
=====================================
my $is_first_file=1;
foreach my $file ( do {
opendir my($dh), "." or die("Can't open directory '.':
$!\n");
sort readdir $dh;
} ) {
$file =~ /\@(40[0-9a-f]+)\.[su]/ or next;
my ($y, $m, $d) = tai64nlocal($1);
next if Delta_Days($year,$month,1, $y,$m,$d)<0;
open( my($fh), "<", $file ) or die("Can't open file $file: $!\n");
while( my($line) = <$fh> ) {
$line =~ /\S(\S*)/ or die("Error 1: $!\n");
my ($y, $m, $d) = tai64nlocal($1);
if ($y==$year and $m==$month) {
push @result, $line;
} elsif ( @result or #1
( $is_first_file and
$.==1 and
Delta_Days($year,$month,$lastday,
$y,$m,$d)>0 )
) {
last THEEND;
}
}
$is_first_file=0;
}
THEEND: if (!@result) {
print "No data.\n";
exit;
"Benjamin Goldberg" <goldbb2@earthlink.net> wrote in message
news:3E0F9671.1DA72071@earthlink.net...
> J.M.Roth wrote:
> [snip]
> > use strict;
> > use warnings;
> > #use diagnostics;
> >
> > use Time::TAI64;
> > use Date::Calc qw(Delta_Days Days_in_Month);
> >
> > ($ARGV[0] && $ARGV[1]) || die("$!: Arguments needed: year month");
>
> I think you mean $0, not $!. And it's more common to write something
> like:
>
> @ARGV == 2 or die "Usage: $0 year month\n";
>
> > my %in;
> > $in{y}=shift;
> > $in{m}=shift;
>
> Why do you put these things in $im{y} and $im{m}? You never do anything
> with them that's well served by being in a hash -- it would be as good,
> or better, to write:
>
> my ($year, $mon) = @ARGV;
>
> > my $qmaillogdir="/var/log/qmail/traffic";
> > my $outfile="$qmaillogdir/qmailsend-$in{y}-$in{m}.out";
> > my $file;
>
> Why declare $file here? It would be better to declare it in the foreach
> loop that it's used.
>
> > my $fc=0;
>
> This isn't a very meaningful variable name. How about $filecount?
>
> > my $already_started=0;
>
> You could just use scalar(@result) anywhere that you use this.
>
> > my $period_over=0;
>
> Looking at how you use this, you'd be better off using a named block,
> and a 'last LABEL' expression in the appropriate place.
>
> .......
>
> There are a number of places where you could avoid a level of
> indentation by exiting (or next'ing) the loop, or the program, in the
> shorter of the two blocks of an if(){}else{}, and reversing the
> condition if necessary.
>
> I would write this program as:
>
>
> use strict;
> use warnings;
> use Time::TAI64;
> use Date::Calc qw(Delta_Days);
>
> @ARGV == 2 or die "Usage: $0 year month\n";
> my ($year, $month) = @ARGV;
> my $lastday = Date::Calc::Days_in_Month($year, $month);
>
> my $qmaildir = "/var/log/qmail/traffic";
> print "Changing directory to $qmaildir.\n";
> chdir( $qmaildir )
> or die "chdir failed: $!\n";
>
> my $outfile = "qmailsend-$year-$month.out";
>
> my @result;
>
> my $is_first_file = 1;
> DIRLOOP: foreach my $file ( do {
> opendir my($dh), "."
> or die "opendir('.') failed: $!\n";
> sort readdir $dh;
> } ) {
> my ($tai_date) = $file =~ /^\@(40[0-9a-f]+)\.[su]/ or next;
> my ($y, $m, $d) = tai64nlocal($tai_date);
> next if Delta_Days( $year, $month, 1 => $y, $m, $d ) < 0;
> open( my($fh), "<", $file )
> or die "Error opening $file: $!";
> while( my $line = <$fh> ) {
> ($tai_date) = $line =~ /\S(\S*)/ or die;
> ($y, $m, $d) = tai64nlocal($tai_date);
> if( $y == $year and $m == $month ) {
> push @result, $line;
> } elseif( @result or $is_first_file and $. == 1 and
> Delta_Days( $year, $month, $lastday, $y, $m, $d ) > 0 ) {
> last DIRLOOP;
> }
> }
> $is_first_file = 0;
> }
>
> if( !@result ) {
> print "No data.\n";
> exit;
> }
>
> open( my($ofh), ">", $outfile )
> or die "Error opening $outfile: $!";
> print "OUT-File is: $outfile\n";
> print $ofh @result;
> close $ofh;
> print "Done.\n";
> __END__
> [untested]
>
> --
> $..='(?:(?{local$^C=$^C|'.(1<<$_).'})|)'for+a..4;
> $..='(?{print+substr"\n !,$^C,1 if $^C<26})(?!)';
> $.=~s'!'haktrsreltanPJ,r coeueh"';BEGIN{${"\cH"}
> |=(1<<21)}""=~$.;qw(Just another Perl hacker,\n);
------------------------------
Date: Mon, 30 Dec 2002 09:18:09 -0600
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: while and eof
Message-Id: <slrnb10oth.4g8.tadmc@magna.augustmail.com>
[ Please learn to quote your followups properly.
http://www.geocities.com/nnqweb/nquote.html
]
J.M.Roth <news@roth.lu> wrote:
[ attribution lost in repairing the TOFU... ]
>> next if Delta_Days( $year, $month, 1 => $y, $m, $d ) < 0;
> By the way, what was the "=>" you were using in the first Delta_Days??
It is usually called a "fat comma".
It is documented in the "List value constructors" section in:
perldoc perldata
---------------------------------------------------
It is often more readable to use the C<< => >> operator between key/value
pairs. The C<< => >> operator is mostly just a more visually distinctive
synonym for a comma, but it also arranges for its left-hand operand to be
interpreted as a string--if it's a bareword that would be a legal identifier.
---------------------------------------------------
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Tue, 31 Dec 2002 00:24:30 -0500
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: while and eof
Message-Id: <3E112A0E.B8092667@earthlink.net>
Please, don't top-post. I've rearranged parts of you post so that your
responses are immediately below what you're responding to.
J.M.Roth wrote:
>
> I agree this looks somewhat cleaner but there is something I can't get
> to work using the new version
[moved]
> =====================================
> my $is_first_file=1;
> foreach my $file ( do {
> opendir my($dh), "." or die("Can't open directory '.': $!\n");
> sort readdir $dh;
> } ) {
> $file =~ /\@(40[0-9a-f]+)\.[su]/ or next;
> my ($y, $m, $d) = tai64nlocal($1);
[I'd formerly had this line here as:
my ($tai_date) = $file =~ /^\@(40[0-9a-f]+)\.[su]/ or next;
my ($y, $m, $d) = tai64nlocal($tai_date);
]
> Also the tai=line=~regexp was bogus, I changed it back to $1.
What do you mean, "was bogus" ? It's perfectly valid syntax. Haven't
you ever used a regex match in list context? The only thing that
*might* have been wrong with it was that in my version, I had the match
anchored at the beginning of the line (the ^ before the \@), and yours
doesn't. Other than that, it should be fine.
> next if Delta_Days($year,$month,1, $y,$m,$d)<0;
> open( my($fh), "<", $file ) or die("Can't open file $file: $!\n");
> while( my($line) = <$fh> ) {
> $line =~ /\S(\S*)/ or die("Error 1: $!\n");
At this point, $! isn't set, since a regex match is NOT a system call.
And the $! variable is *only* valid after you've performed some system
function or other, and it's failed.
So you'll either get "Error 1: <garbage>\n", or just "Error 1: \n" ...
which is not especially useful.
If you want to include an error string here, it should be a bit more
descriptive -- in particular, indicate $file, $., and $line, and the
fact that you were expecting it to have some non-whitespace characters,
and there weren't any.
> my ($y, $m, $d) = tai64nlocal($1);
> if ($y==$year and $m==$month) {
> push @result, $line;
> } elsif ( @result or #1
> I've marked a line below with #1. I can't make it to the else if, even
> if ($y==$year and $m==$month) is false... ?
Obviously, you're reaching the elsif *condition*, but the condition for
entering the elsif block is failing.
> In fact the debugger tells me it quits right at the if, i.e. after the
> if line there is immediately $is_first_file=0 ...
Umm, if $is_first_file is zero, then it shouldn't be going into the
elsif block. Which is, according to your comment elsewhere, precisely
what you want.
> ( $is_first_file and
> $.==1 and
> Delta_Days($year,$month,$lastday, $y,$m,$d)>0
> )
> ) {
> last THEEND;
> I also changed the label somewhat, I don't need to jump to the next
> file if the elseif is met.
I'm not sure what you mean here ... in my version, "last DIRLOOP" simply
exits from the loop labeled "DIRLOOP". Yours tries to "last" from a
nonexistant closing block. I'd be quite surprised if yours didn't die
at this point with an error message saying that.
> If the elseif is met, I either
> 1. have all the results I need (@result) or
> 2. it is at the very beginning and there are no results (
> $is_first_file and $.==1 and
> Delta_Days($year,$month,$lastday, $y,$m,$d)>0
> )
Sounds about like what's happening.
> By the way, what was the "=>" you were using in the first Delta_Days??
It's a comma.
[big snip]
If you'd like to be able to see what's happening a bit more clearly,
consider rewriting the inside of the while loop as:
while( my $line = <$fh> ) {
($tai_date) = $line =~ /\S(\S*)/ or die;
($y, $m, $d) = tai64nlocal($tai_date);
(push @result, $line), next
if $y == $year and $m == $month;
last DIRLOOP if @result;
next unless $is_first_file;
next unless $. == 1;
next unless
Delta_Days( $year, $month, $lastday => $y, $m, $d ) > 0;
last DIRLOOP;
}
PS: I would seriously suggest that when posting your code to usenet, you
change the indentation to a 3 or 4 spaces -- that way, your lines fit
within the standard 72 columns.
--
$..='(?:(?{local$^C=$^C|'.(1<<$_).'})|)'for+a..4;
$..='(?{print+substr"\n !,$^C,1 if $^C<26})(?!)';
$.=~s'!'haktrsreltanPJ,r coeueh"';BEGIN{${"\cH"}
|=(1<<21)}""=~$.;qw(Just another Perl hacker,\n);
------------------------------
Date: Tue, 31 Dec 2002 09:18:29 GMT
From: inwap@inwap.com (Joe Smith)
Subject: Re: while and eof
Message-Id: <FhdQ9.1557$io.68340@iad-read.news.verio.net>
In article <3e0f865c_2@news.vo.lu>, J.M.Roth <news@roth.lu> wrote:
>But doesn't it take more processing time redeclaring them
>over and over again than if I simply kept them global?
Perl is smarter than that; don't waste time attempting micro-optimizations.
--
See http://www.inwap.com/ for PDP-10 and "ReBoot" pages.
------------------------------
Date: 30 Dec 2002 10:11:50 -0800
From: J_Steven_Walker@hotmail.com (Steve Walker)
Subject: Re: Wierd loop/chdir behavior
Message-Id: <534c971c.0212301011.542cacb4@posting.google.com>
Benjamin Goldberg <goldbb2@earthlink.net> wrote in message news:<3E04D4E3.D14E04C6@earthlink.net>...
> Steve Walker wrote:
> >
> > Anybody have an idea what is going on here?
> >
> > Background:
> >
> > goal - build a configuration file parser (yes, I know there is a
> > package now but I didn't then) for use by a perl script.
>
> Actually, there are a number of packages for parsing configuration
> files. Some of this is because there are various different syntaxes for
> how to write a config file, and some is because different people prefer
> different APIs.
No doubt, and some are mentioned in this thread. I would love to know
all about them but are they part of the base distribution or an add on
package? As I am still building my competency in PERL and also have
my REAL work to accomplish, I have to be careful that I don't wander
off into Perland and forget my way back. For now, I stick to the base
package and what is documented there. Even that is a lot to digest -
I was tempted to delve into Perl debugger but suspect that this, too,
might drink deep of the time available. Maybe someday...
>
> > requirements -
> > 1) since script will use 'find' on a directory that includes
> > symbolic links and I don't want to include '-follow', paths configured
> > to be searched should be globbed/converted to an absolute path before
> > use.
>
> 1/ When you say it will use 'find', do you mean it will use the
> File::Find module's function &find, or do you mean that the script will
> use the external 'find' program?
>
> 2/ Why should a path being a symbolic link prevent find from working on
> it?
The items in the configuration file will likely be symbolic links.
Additionally, the directories that are the targets of these links may
also contain symbolic links. I will be using the system program
'find' to locate a particular file in the configured path but I don't
want to traverse any of the symbolic links in the target directory.
The behavior of 'find' is such that if the configured path is a
symbolic link the '-follow' option would be required to get to the
target directory. 'find' applies the -follow option globally so every
symbolic link would be followed.
In my case this would result in a lot of activity in areas I already
know will not be productive but will waste a lot of CPU time.
If, however I provide an absolute path to 'find', I don't need the
-follow option and symbolic links within the target directories are
not followed.
>
> 3/ What does glob have to do with symbolic links? It doesn't expand
> them, you know. Do you mean readlink()?
>
> > 2) multiple target paths are to be considered
> >
> > Sample config: (file name clarit.conf)
> >
> > BuildPath=~/Data/build
> > ActivePath=Data/active
> > NewDataPath=~/epaa:~/epab:~/epac:~/epaa:~/epab:~/epac
> > WebPath=~/clhtml
>
> Hmm... these paths all have tildes in them -- afaik, only the shell, and
> glob, directly understand what ~user/path and ~/path mean. Is this why
> you wanted to use glob() on the paths here?
Yes, in part. It was my desire to have a complete and competent
preprocessing of the configuration file paths to reduce them to simple
paths (no special characters or wildcards) If I were to require that
no wildcards be included I could have simply used the path in chdir
and then 'pwd' to achieve the requirements above, but glob() seemed to
offer a more universal solution, wildcards included (especially in
hindsight - note my first code sample would only have used the first
path returned... what can I say - it was try-it-and-learn code).
>
> sub tilde_expand($) {
> my $path = shift;
> $path =~ s/([^\w~])/\\$1/g;
> (glob($path))[0];
> }
Ben, thanks again for your help. I am new to usenet but I am learning
how educational it can be. Lots of interesting problems to work out -
oops, there's that time sucking sound again...
gotta go,
S.
------------------------------
Date: 30 Dec 2002 10:57:45 -0800
From: J_Steven_Walker@hotmail.com (Steve Walker)
Subject: Re: Wierd loop/chdir behavior
Message-Id: <534c971c.0212301057.42a21376@posting.google.com>
tadmc@augustmail.com (Tad McClellan) wrote in message news:<slrnb068k2.31i.tadmc@magna.augustmail.com>...
> Steve Walker <J_Steven_Walker@hotmail.com> wrote:
>
> > @gdir=glob ($ddir);
>
> > foreach $dir (@gdir)
>
>
> You do not need that temporary variable
>
No doubt true and originaly I didn't use one, but as an aid to
understanding what was going on, put one in so I could print the
result (print now deleted)
- but us newbies like simple steps anyway to make things clear in
preference to terse one-liners.
I believe that glob would understand this foreach to be a list context
rather than scalar context - can you confirm?
> foreach $dir ( glob($ddir) )
>
>
> > chdir $work_dir ;
>
>
> Just because you asked to change directories doesn't mean
> you actually got what you asked for.
>
> You should check the return value:
>
> chdir $work_dir or die "could not chdir to '$work_dir' $!";
>
>
> > if (defined($dir))
>
>
> What is that test for?
>
> glob() does not return undefs.
Well, yes and no. I think I agree that in this context there would be
no undefined items presented, however, to pick-a-nit, the docs
indicate that glob CAN return undefined (which is what I was likely
thinking about when I did the code - and it does work, even if it is a
waste of time). Note perldoc -f glob:
glob In list context, returns a (possibly empty) list of filename
expansions on the value of EXPR such as the standard Unix
shell
/bin/csh would do. In scalar context, glob iterates through
such
filename expansions, returning undef when the list is
exhausted.
I confess that I am unclear as to how the iteration of a scalar
context actually occurs. I know that the C function 'strtok' for
parsing a string bookmarks a position in the string for each call to
the function and perhaps this is the way glob works in scalar context.
It might be interesting to try to do the iteration in scalar context
but I haven't.
>
>
> > chop($pwd=`/usr/bin/pwd`);
>
>
> chomp($pwd=`/usr/bin/pwd`);
------------------------------
Date: Mon, 30 Dec 2002 20:51:12 +0100
From: "Harald H.-J. Bongartz" <bongie@gmx.net>
Subject: Re: Wierd loop/chdir behavior
Message-Id: <104129689.Ev4Rm7KM6h@nyoga.dubu.de>
Steve Walker wrote:
> Note perldoc -f glob:
>
> glob In list context, returns a (possibly empty) list of filename
> expansions on the value of EXPR such as the standard Unix shell
> /bin/csh would do. In scalar context, glob iterates through such
> filename expansions, returning undef when the list is exhausted.
>
> I confess that I am unclear as to how the iteration of a scalar
> context actually occurs. I know that the C function 'strtok' for
> parsing a string bookmarks a position in the string for each call to
> the function and perhaps this is the way glob works in scalar context.
Same for the pattern matching and substitute operators m// and s/// when
used with the option /g.
> It might be interesting to try to do the iteration in scalar context
> but I haven't.
while ($onefile = glob("*.c")) {
# do something with $onefile
}
similar:
my $str = "abcadfaghaijkl";
while ($str =~ /(a.)/g) {
print "$1#";
}
__END__
ab#ad#ag#ai#
Ciao,
Harald
--
Harald H.-J. Bongartz <bongie@gmx.net>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
++$sheep while !$asleep;
------------------------------
Date: Tue, 31 Dec 2002 03:47:37 -0500
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Wierd loop/chdir behavior
Message-Id: <3E1159A9.8234FCF0@earthlink.net>
Steve Walker wrote:
> Benjamin Goldberg wrote:
[snip]
> > > requirements -
> > > 1) since script will use 'find' on a directory that
> > > includes symbolic links and I don't want to include '-follow',
> > > paths configured to be searched should be globbed/converted to an
> > > absolute path before use.
> >
> > 1/ When you say it will use 'find', do you mean it will use the
> > File::Find module's function &find, or do you mean that the script
> > will use the external 'find' program?
> >
> > 2/ Why should a path being a symbolic link prevent find from working
> > on it?
>
> The items in the configuration file will likely be symbolic links.
> Additionally, the directories that are the targets of these links may
> also contain symbolic links. I will be using the system program
> 'find' to locate a particular file in the configured path but I don't
> want to traverse any of the symbolic links in the target directory.
>
> The behavior of 'find' is such that if the configured path is a
> symbolic link the '-follow' option would be required to get to the
> target directory. 'find' applies the -follow option globally so every
> symbolic link would be followed.
Actually, no, it doesn't.
Firstly, if the symbolic link in question is one of the directories that
you tell find to start searching at, it will resolve it to a 'real'
directory regardless of whether or not -follow is set.
Secondly, you can conditionally set -follow, in the same way that you
would conditionally set -prune, by using "\(", "\)", and "-o".
[of course, both of these are dependent on your system's implementation
of find, so this might not be true on your system]
.... And, now that I know how you're using the path with find, I see
that a full resolution to a *completely* absolute path isn't necessary;
you only need to resolve the last piece to not being a symlink, as
follows:
use File::Spec;
$file = File::Spec->rel2abs( $file );
while( -l $file ) {
defined( my $link = readlink( $file ) ) or die $!;
$file = File::Spec->rel2abs( $link, $file );
}
--
$..='(?:(?{local$^C=$^C|'.(1<<$_).'})|)'for+a..4;
$..='(?{print+substr"\n !,$^C,1 if $^C<26})(?!)';
$.=~s'!'haktrsreltanPJ,r coeueh"';BEGIN{${"\cH"}
|=(1<<21)}""=~$.;qw(Just another Perl hacker,\n);
------------------------------
Date: Tue, 31 Dec 2002 09:57:35 +0100
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Yet Another Question About: "my" and scope of vars...
Message-Id: <bkl21voakq5jtekmna01n2aroh8q7ihtua@4ax.com>
While writing yet another url extraction script (and yes: I know the
relevant faq entry), I realized that the following portion of code
does not "work"
/href\s*=\s*([\"\'])([^\"\']+)\1/i and push my @urlz, $2 while (<>);
whereas this does:
my @urlz;
/href\s*=\s*([\"\'])([^\"\']+)\1/i and push @urlz, $2 while (<>);
Now, I guess that this is well documented somewhere, but my question
is why the 1st form is not "allowed": first, it does NOT yield any
error/warning with -w and 'use strict'; second, I'm declaring the
array @urlz the first time I use it in a statement and so it should be
a lexical within the scope "enclosing" that statement...
Should I argue that there's an implicit block as if the cycle were
explicitly written as 'while (<>) {...}'? But then why can I use @urlz
with no warning in the following statments (only that it's empty)?
TIA,
Michele
--
>It's because the universe was programmed in C++.
No, no, it was programmed in Forth. See Genesis 1:12:
"And the earth brought Forth ..."
- Robert Israel on sci.math, thread "Why numbers?"
------------------------------
Date: Tue, 31 Dec 2002 10:08:24 +0100
From: Koos Pol <koos_pol@NO.nl.JUNK.compuware.MAIL.com>
Subject: Re: Yet Another Question About: "my" and scope of vars...
Message-Id: <newscache$028z7h$mi2$1@news.emea.compuware.com>
Michele Dondi wrote (Tuesday 31 December 2002 09:57):
> While writing yet another url extraction script (and yes: I know the
> relevant faq entry), I realized that the following portion of code
> does not "work"
>
> /href\s*=\s*([\"\'])([^\"\']+)\1/i and push my @urlz, $2 while (<>);
In this case a new @url will be "my"-ied on each iteration.
--
KP
------------------------------
Date: 31 Dec 2002 22:17:57 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Yet Another Question About: "my" and scope of vars...
Message-Id: <aut52l$pgb$4@mamenchi.zrz.TU-Berlin.DE>
Michele Dondi <bik.mido@tiscalinet.it> wrote in comp.lang.perl.misc:
> While writing yet another url extraction script (and yes: I know the
> relevant faq entry), I realized that the following portion of code
> does not "work"
>
> /href\s*=\s*([\"\'])([^\"\']+)\1/i and push my @urlz, $2 while (<>);
>
> whereas this does:
>
> my @urlz;
> /href\s*=\s*([\"\'])([^\"\']+)\1/i and push @urlz, $2 while (<>);
>
> Now, I guess that this is well documented somewhere, but my question
> is why the 1st form is not "allowed": first, it does NOT yield any
> error/warning with -w and 'use strict'; second, I'm declaring the
> array @urlz the first time I use it in a statement and so it should be
> a lexical within the scope "enclosing" that statement...
Scope is not your problem (if it were, Perl would have complained). It's
the run-time effect of my() that spoils it: Each time you run through
my() it gives you a fresh variable, so you lose what you want to accumulate.
This behavior is expected and useful in larger loops, so Perl can't
treat it as an error.
Anno
------------------------------
Date: Tue, 31 Dec 2002 23:43:24 +0100
From: "Thomas Dehn" <thomas-usenet@arcor.de>
Subject: Re: Yet Another Question About: "my" and scope of vars...
Message-Id: <3e121cf9_1@news.arcor-ip.de>
"Michele Dondi" <bik.mido@tiscalinet.it> wrote:
> While writing yet another url extraction script (and yes: I know the
> relevant faq entry), I realized that the following portion of code
> does not "work"
>
> /href\s*=\s*([\"\'])([^\"\']+)\1/i and push my @urlz, $2 while (<>);
Oh, this code does work *snicker*.
The very problem is that the code works ;-).
Thomas
------------------------------
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.
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 V10 Issue 4329
***************************************
