[32346] in Perl-Users-Digest
Perl-Users Digest, Issue: 3613 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 17 14:09:25 2012
Date: Fri, 17 Feb 2012 11:09:07 -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 Fri, 17 Feb 2012 Volume: 11 Number: 3613
Today's topics:
Re: Elegant ways to convert '' or 'number' to a number (Seymour J.)
Re: Elegant ways to convert '' or 'number' to a number <rweikusat@mssgmbh.com>
Re: Elegant ways to convert '' or 'number' to a number <cartercc@gmail.com>
Re: Elegant ways to convert '' or 'number' to a number (Seymour J.)
Re: Elegant ways to convert '' or 'number' to a number <rweikusat@mssgmbh.com>
Re: Elegant ways to convert '' or 'number' to a number (Tim McDaniel)
Re: Elegant ways to convert '' or 'number' to a number <hjp-usenet2@hjp.at>
Re: Elegant ways to convert '' or 'number' to a number <hjp-usenet2@hjp.at>
Re: Elegant ways to convert '' or 'number' to a number <hjp-usenet2@hjp.at>
Re: Elegant ways to convert '' or 'number' to a number <hjp-usenet2@hjp.at>
File::Slurp and reading files in general <NoSpamPleaseButThisIsValid3@gmx.net>
Re: sorting unicode file under windows command line <ehabaziz2001@gmail.com>
Re: sorting unicode file under windows command line <jimsgibson@gmail.com>
Using loop labels and iterating. <rodbass63@gmail.com>
Re: Using loop labels and iterating. <thepoet_nospam@arcor.de>
Re: Using loop labels and iterating. <ben@morrow.me.uk>
Re: Using loop labels and iterating. <rweikusat@mssgmbh.com>
Re: Using loop labels and iterating. <rweikusat@mssgmbh.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 16 Feb 2012 04:30:12 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Elegant ways to convert '' or 'number' to a number
Message-Id: <4f3ccca4$3$fuzhry+tra$mr2ice@news.patriot.net>
In <87ty2s6ruq.fsf@sapphire.mobileactivedefense.com>, on 02/15/2012
at 03:25 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>They are not different concepts and Perl and have never been
>different concepts in Perl:
Nonsense; interpolating an empty string does not produce a warning.
There are certainly cases where you can ignore the difference, but the
difference is nonetheless real.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Thu, 16 Feb 2012 15:55:45 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Elegant ways to convert '' or 'number' to a number
Message-Id: <87hayqrcvy.fsf@sapphire.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>tmcd@panix.com (Tim McDaniel) writes:
>>> Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>>>>tmcd@panix.com (Tim McDaniel) writes:
[...]
>>>>>>By 'null string' you mean an empty string, not undef, right?
>>>>>
>>>>> Yes. I agree with Cerebron on dragons: the concepts ought to be
>>>>> kept rigidly distinct.
>>>>
>>>>They are not different concepts and Perl and have never been
>>>>different concepts in Perl
>>>
>>> They can be distinguished via defined(). They cause different
>>> warnings (uninitialized value).
>>
>>They are not disinguishable for their 'string value' because
>>automatic conversions are done by Perl as required
>
> Nevertheless, they are different concepts, although there is only one
> place (defined()) where code can tell the difference, so far as I
> know.
They are 'something different' at the perl implementation level. If
they are also 'something different' for a particular application of
Perl to some problem depends on the problem: Values usually have types
and such a type is the set of all valid values for a particular
'thing'. If this set includes some kind of 'null value', something
which is technically legitimate but no operations save than comparing
it to other valid values may be used on it and the result will always
be "it's differen", Perl default-value scalars can be used to
represent this 'null value'. An example of that would be DBI which
represents the SQL concept of 'the null value' in this way. OTOH, if
I'm dealing with the values from the mod 256 factor ring, treating the
same default value scalar as a variable which is automatically
initialized to a value of 0 will often be more convenient, no matter
how thoroughly the very idea combs zealous beancounters against the
grain (I have no idea if this works in English, just some web-research
based hopes that it does).
------------------------------
Date: Thu, 16 Feb 2012 11:23:02 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: Elegant ways to convert '' or 'number' to a number
Message-Id: <7a729974-b1fd-447f-aef8-76abed076634@18g2000yqe.googlegroups.com>
On Feb 15, 6:10=A0pm, t...@panix.com (Tim McDaniel) wrote:
> >What's wrong with using int(),
>
> The part about "without producing a warning if it happens to be a null st=
ring".
Sorry, I guess I didn't notice that.
Here is a common idiom that I employ a lot:
$x ||=3D 0;
Obviously, this only applies when $x does not contain any value.
When validating data, for example, ensuring that a field contains
something similar to an email address, I do this a lot:
$x ||- 'my_email@some.com';
or
$x =3D 'my_email@some.com' unless $x =3D~ /\w+\@.\w+/;
Finally, if you automate your scripts, perhaps by using a cron job or
a scheduled task, no one sees the warnings. In many (most?) of my
production scripts, I don't disable warnings. My users never see the
warnings, but only the output -- however, when I run the scripts in
real time, I see the warnings, and somehow that reassures me that
everything's right with the world.
CC.
------------------------------
Date: Thu, 16 Feb 2012 11:55:57 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: Elegant ways to convert '' or 'number' to a number
Message-Id: <4f3d351d$16$fuzhry+tra$mr2ice@news.patriot.net>
In <87hayqrcvy.fsf@sapphire.mobileactivedefense.com>, on 02/16/2012
at 03:55 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>They are 'something different' at the perl implementation level.
They are also something different in the Perl documentation, e.g.,
perlsyn distinguishes them.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Thu, 16 Feb 2012 20:21:01 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Elegant ways to convert '' or 'number' to a number
Message-Id: <878vk2r0lu.fsf@sapphire.mobileactivedefense.com>
ccc31807 <cartercc@gmail.com> writes:
[...]
> Finally, if you automate your scripts, perhaps by using a cron job or
> a scheduled task, no one sees the warnings.
FYI: Usually, cron will mail the stdout and stderr output of a cronjob to
the user whose cronjob it was.
------------------------------
Date: Thu, 16 Feb 2012 20:55:38 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Elegant ways to convert '' or 'number' to a number
Message-Id: <jhjqga$fl9$1@reader1.panix.com>
In article <87hayqrcvy.fsf@sapphire.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>If they are also 'something different' for a particular application
>of Perl to some problem depends on the problem
Hm. I think I agree with your point. Perhaps I might put it that,
from the point of view of "duck typing", what matter is what you want
to do with it and what the language conveniently allows.
I'm not sure whether it's my FORTRAN and C background, or my general
anal-retentiveness, that makes me focus too much on types and to look
with suspicion on Perl's builtin conversions, instead of relaxing and
letting Perl deal with it -- in the case I was asking about, letting
the "==" operator handle the conversion.
>no matter how thoroughly the very idea combs zealous beancounters
>against the grain (I have no idea if this works in English, just some
>web-research based hopes that it does).
"Beancounter", as I've heard it, refers specifically to accountants,
and that word doesn't have connotations that work here. I'd say
"no matter how thoroughly the very idea rubs pedants the wrong way".
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Fri, 17 Feb 2012 18:58:42 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Elegant ways to convert '' or 'number' to a number
Message-Id: <slrnjjt5ai.sif.hjp-usenet2@hrunkner.hjp.at>
On 2012-02-16 20:21, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> ccc31807 <cartercc@gmail.com> writes:
>> Finally, if you automate your scripts, perhaps by using a cron job or
>> a scheduled task, no one sees the warnings.
>
> FYI: Usually, cron will mail the stdout and stderr output of a cronjob to
> the user whose cronjob it was.
Right. And getting a mail with a warning every 10 minutes should be
enough enough motivation to fix the problem fast (of course some people
would rather implement a mail filter to automatically delete all mails
from cron ...)
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Fri, 17 Feb 2012 19:07:16 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Elegant ways to convert '' or 'number' to a number
Message-Id: <slrnjjt5ql.sif.hjp-usenet2@hrunkner.hjp.at>
On 2012-02-15 22:52, Graham Drabble <usenet05@drabble.me.uk> wrote:
> On 14 Feb 2012 tmcd@panix.com (Tim McDaniel) wrote in
> news:jhek67$dpd$1@reader1.panix.com:
>> So a cow-orker has the result of a database query. It's being
>> returned as a string: it contains an integer or it's a null
>> string.
>
> Has he though of changing the query. You don't say what DB he's using
> but the following should work in MSSQL and I would expect similar to
> be possible in other DBMSs.
>
> Instead of
> "SELECT
> column
> from table"
>
> use
>
> "SELECT
> case
> when column is null then 0
> else column
> end
> from table"
Tim already wrote (unless I misunderstood him), that the value is
actually "", not undef. DBI always returns undef for NULL, so that
wouldn't help. (This also means that the column has almost certainly a
varchar type, not a number type, which hints at a deeper database design
problem - but unfortunately we often have to live with databases as they
are and can't fix them).
Somethingh like
SELECT
case column
when '' then 0
else column
end
from table
should work, though.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Fri, 17 Feb 2012 19:14:59 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Elegant ways to convert '' or 'number' to a number
Message-Id: <slrnjjt693.sif.hjp-usenet2@hrunkner.hjp.at>
On 2012-02-16 09:30, Shmuel Metz <spamtrap@library.lspace.org.invalid> wrote:
> In <87ty2s6ruq.fsf@sapphire.mobileactivedefense.com>, on 02/15/2012
> at 03:25 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>>They are not different concepts and Perl and have never been
>>different concepts in Perl:
>
> Nonsense; interpolating an empty string does not produce a warning.
> There are certainly cases where you can ignore the difference, but the
> difference is nonetheless real.
More importantly: If Larry had intended undef to to conceptually the
same as an empty string he wouldn't have bothered to implement undef
at all. Why implement a special value with a special keyword if it's
just the same as an empty string? So Larry considered it important to be
able to distinguish between undef (no value, missing value, unknown
value, ...) and the empty string or 0, even if he provided for automatic
conversion.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Fri, 17 Feb 2012 19:32:57 +0100
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Elegant ways to convert '' or 'number' to a number
Message-Id: <slrnjjt7ap.sif.hjp-usenet2@hrunkner.hjp.at>
On 2012-02-15 22:17, ccc31807 <cartercc@gmail.com> wrote:
> On Feb 14, 4:37 pm, t...@panix.com (Tim McDaniel) wrote:
>> So a cow-orker has the result of a database query. It's being
>> returned as a string: it contains an integer or it's a null string.
>> (Yes, we're certain.) He wants to use it in a numeric context,
>> Is there an elegant idiom for converting such a string to a number
>> without producing a warning if it happens to be a null string?
>
> What's wrong with using int(), or sprintf()?
>
> I had a similar problem, but the reverse. I used person ID numbers as
> keys in a hash table, and manipulated the values in various ways,
> which included Microsoft Excel. I kept getting aggravating errors over
> a long time, and after one experience went through the results line by
> line and discovered that sometimes ID numbers with leading zeros were
> treated like real numbers, and a value like '4321' does not match a
> hash key like '0004321'.
Well, you have to know your data: Perl itself won't convert a string
'0004321' into the number 4321 unless you force it to. Contrary to what
Rainer probably thinks numbers and strings aren't the same in Perl and
if you keep a mental model of what your values actually are it isn't
actually that hard to prevent accidental type conversions.
> I started using sprintf() when in doubt, and it solved the problem. I
> just convert whatever the value is into a string, and it preserves the
> leading zeros.
You haven't shown the sprintf invokation you use but I don't think so.
It may *add* leading zeros if they got lost, but it cannot preserve
them.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Fri, 17 Feb 2012 17:43:31 +0100
From: Wolf Behrenhoff <NoSpamPleaseButThisIsValid3@gmx.net>
Subject: File::Slurp and reading files in general
Message-Id: <4f3e83b4$0$6571$9b4e6d93@newsspool3.arcor-online.net>
Am 17.02.2012 16:46, schrieb Rainer Weikusat:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
> [...]
>
>> OTOH, the source code of that was 'an interesting read'.
Talking about this:
what is actually the advantage of sysread over the "Perl way" of reading
from a file with code like $result = <$fileHande> (or @result =
<$fileHandle>, depending on wantarray)? To slurp, I simply undef $/ and
everything seems fine... I have never used sysread in Perl - should I
consider using it?
I didn't expect such a long code for some "simple" thing like reading in
a file, especially not a comment telling me it is using "DEEP DARK MAGIC".
As I am usually using an "enterprise" Linux distribution (RHEL clone), I
still need to make scripts compatible with 5.8.8 where File::Slurp is
not a core module...
- Wolf
------------------------------
Date: Fri, 17 Feb 2012 03:00:16 -0800 (PST)
From: happytoday <ehabaziz2001@gmail.com>
Subject: Re: sorting unicode file under windows command line
Message-Id: <c2e04dbd-3586-4eb8-83fa-4a3e724e06cf@db5g2000vbb.googlegroups.com>
On Feb 14, 7:40=C2=A0pm, "George Mpouras"
<nospam.gravitalsun.antis...@hotmail.com.nospam> wrote:
> #!c:/Perl/bin/perl.exe
> # Have a happy sorting
>
> use encoding 'utf8';
> my @File;
> my %Positions_and_lenghts =3D (
> 0 =3D> 1 ,
> 2 =3D> 1 ,
> 4 =3D> 4 ,
> 9 =3D> 6 ,
> );
>
> #For external file
> #open FILE, '>:utf8', 'c:/ome/utf8/file' or die "$^E\n";
> binmode STDOUT, ':utf8';
>
> while (my $line =3D <DATA>) {
> my $row;
> =C2=A0 =C2=A0 foreach my $POS (sort {$a<=3D>$b} keys %Positions_and_lengh=
ts) {
> =C2=A0 =C2=A0 push @{$row}, substr $line, $POS, $Positions_and_lenghts{$P=
OS}
> =C2=A0 =C2=A0 }
> push @File, $row}
>
> #use Data::Dumper; print Dumper(\@File);exit;
>
> foreach my $row (sort {$a->[0] cmp $b->[0] || $a->[2] cmp $b->[2]} @File)=
{
> print "@{$row}\n"
>
> }
>
> __DATA__
> 1 a =CE=B1=CE=B1 =CE=B4=CE=B4=CE=B4
> 1 b =CE=B2=CE=B2 =CE=B3=CE=B3=CE=B3
> 2 a =CE=B1=CE=B1 =CE=B2=CE=B2=CE=B2
> 2 b =CE=B2=CE=B2 =CE=B1=CE=B1=CE=B1
Regarding the perl script I tried :
C:\COMPILER\Perl\bin>perl -c sorting.pl sorting.txt
sorting.pl syntax OK
use encoding 'utf8';
my @File;
my %Positions_and_lenghts =3D (
0 =3D> 1 ,
2 =3D> 1 ,
4 =3D> 4 ,
70 =3D> 9 ,
);
#For external file
open FILE, '>:utf8', 'c:\compiler\bin\perl\sorting.txt' or die "$^E
\n";
binmode STDOUT, ':utf8';
while (my $line =3D <DATA>) {
my $row;
foreach my $POS (sort {$a<=3D>$b} keys %Positions_and_lenghts) {
push @{$row}, substr $line, $POS, $Positions_and_lenghts{$POS}
}
push @File, $row
}
#use Data::Dumper; print Dumper(\@File);exit;
foreach my $row (sort {$a->[0] cmp $b->[0] || $a->[2] cmp $b->[2]}
@File) {
print "@{$row}\n"
}
but nothing happened .
------------------------------
Date: Fri, 17 Feb 2012 10:30:11 -0800
From: Jim Gibson <jimsgibson@gmail.com>
Subject: Re: sorting unicode file under windows command line
Message-Id: <170220121030119623%jimsgibson@gmail.com>
In article
<c2e04dbd-3586-4eb8-83fa-4a3e724e06cf@db5g2000vbb.googlegroups.com>,
happytoday <ehabaziz2001@gmail.com> wrote:
>
> Regarding the perl script I tried :
>
> C:\COMPILER\Perl\bin>perl -c sorting.pl sorting.txt
> sorting.pl syntax OK
>
[program snipped]
>
> but nothing happened .
If you mean nothing happened after you entered the following:
perl -c sorting.pl sorting.txt
that is because the -c flag tells perl to check the syntax of your
program but do not run it. That is what happened. Is that what you did?
If not, please explain further.
--
Jim Gibson
------------------------------
Date: Thu, 16 Feb 2012 19:22:54 -0800 (PST)
From: Nene <rodbass63@gmail.com>
Subject: Using loop labels and iterating.
Message-Id: <7e35a621-a124-4e66-8505-5d70d7a04c5d@j15g2000yqb.googlegroups.com>
Hi,
This is a script that opens up a log file and searches for the word
'started' and if it finds the word, it prints it and iterates to the
next log file. But for the servers that didn't start, I want it to
print "didn't start". Please help, thanks.
#!/usr/bin/perl
use diagnostics;
use warnings;
open(SCRATCHPAD,"LOG.txt") or die "can't open $!";
my @uniq = <SCRATCHPAD>;
NODE:
foreach my $stuff ( @uniq ) {
chomp($stuff);
open(STARTUP, "/c\$/$stuff/esp.log") or "die can't open $!";
my @log_file = <STARTUP>;
LINE:
for my $line ( @log_file ) {
next LINE if $line !~ /ESP server (started)./;
my $capture = "$1\n";
print "$stuff => $capture";
close(STARTUP);
close(SCRATCHPAD);
}
}
------------------------------
Date: Fri, 17 Feb 2012 06:48:21 +0100
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: Using loop labels and iterating.
Message-Id: <4f3dea1f$0$6577$9b4e6d93@newsspool3.arcor-online.net>
Am 17.02.2012 04:22, schrieb Nene:
> This is a script that opens up a log file and searches for the word
> 'started' and if it finds the word, it prints it and iterates to the
> next log file. But for the servers that didn't start, I want it to
> print "didn't start". Please help, thanks.
>
>
>
> #!/usr/bin/perl
> use diagnostics;
> use warnings;
>
> open(SCRATCHPAD,"LOG.txt") or die "can't open $!";
> my @uniq =<SCRATCHPAD>;
>
> NODE:
> foreach my $stuff ( @uniq ) {
> chomp($stuff);
>
> open(STARTUP, "/c\$/$stuff/esp.log") or "die can't open $!";
> my @log_file =<STARTUP>;
>
> LINE:
> for my $line ( @log_file ) {
>
> next LINE if $line !~ /ESP server (started)./;
> my $capture = "$1\n";
> print "$stuff => $capture";
>
> close(STARTUP);
> close(SCRATCHPAD);
>
> }
> }
It's good that you have diagnostics and warnings enabled.
Especially with variables in the filename expression of
your open statements, you should use the three argument
form.
Your example code has a number of issues: Your second die
statement is broken (the die's inside the string), you
close the outer file multiple times inside the loop, and
a little bit of indentation would go a long way in making
it more legible.
You don't say if you plan to do more processing of the
server names later on, which would merit storing them in
@uniq, or not. For sake of conserving memory I've omitted
doing that and just iterate over the file line by line.
I hope the code below is self-explanatory enough.
--------------------------------------------------------
#!/usr/bin/perl
use diagnostics;
use warnings;
open(my $scratchpad, "<", "LOG.txt")
or die "can't open LOG.txt: $!";
while( my $stuff = <$scratchpad> )
{
my $status = "didn't start";
chomp $stuff;
open( my $startup, "<", "/c\$/$stuff/esp.log" )
or die "can't open $stuff/esp.log: $!";
LINE: while( my $line = <$startup> )
{
if( $line =~ /ESP server (started)/ )
{
$status = $1;
last LINE;
}
}
close $startup;
print "$stuff => $status$/";
}
close $scratchpad;
--------------------------------------------------------
-Chris
------------------------------
Date: Fri, 17 Feb 2012 06:54:11 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Using loop labels and iterating.
Message-Id: <j5a119-jov2.ln1@anubis.morrow.me.uk>
Quoth Christian Winter <thepoet_nospam@arcor.de>:
>
> open( my $startup, "<", "/c\$/$stuff/esp.log" )
> or die "can't open $stuff/esp.log: $!";
>
> LINE: while( my $line = <$startup> )
> {
> if( $line =~ /ESP server (started)/ )
> {
> $status = $1;
> last LINE;
> }
> }
>
> close $startup;
> print "$stuff => $status$/";
use File::Slurp qw/slurp/;
my $startup = slurp "/c\$/$stuff/esp.log";
$startup =~ /ESP server started/
and print "$stuff => started\n";
Unless the logfile is *huge* (by which I mean several GB, these days),
it's going to be more efficient to read and match it all in one go.
$/ is the input line separator. It isn't usually right to use it as the
output separator. You can avoid having to print separators at all by
setting $\, or using 5.10's 'say'.
If you'd rather avoid File::Slurp (though there's no good reason you
should),
my $startup = do {
open my $STARTUP, "<", "..." or die ...;
local $/ = undef;
<$STARTUP>
};
Oh, and my usual plug for 'autodie', which will add all those 'or die's
for you.
Ben
------------------------------
Date: Fri, 17 Feb 2012 13:38:07 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Using loop labels and iterating.
Message-Id: <87ipj5r35s.fsf@sapphire.mobileactivedefense.com>
Ben Morrow <ben@morrow.me.uk> writes:
> Quoth Christian Winter <thepoet_nospam@arcor.de>:
>>
>> open( my $startup, "<", "/c\$/$stuff/esp.log" )
>> or die "can't open $stuff/esp.log: $!";
>>
>> LINE: while( my $line = <$startup> )
>> {
>> if( $line =~ /ESP server (started)/ )
>> {
>> $status = $1;
>> last LINE;
>> }
>> }
>>
>> close $startup;
>> print "$stuff => $status$/";
>
> use File::Slurp qw/slurp/;
>
> my $startup = slurp "/c\$/$stuff/esp.log";
> $startup =~ /ESP server started/
> and print "$stuff => started\n";
>
> Unless the logfile is *huge* (by which I mean several GB, these days),
> it's going to be more efficient to read and match it all in one go.
It is probably going to be faster which might be a good thing if the
assumption that the machine is exclusively dedicated to this
particular task holds because it will then hog CPU and memory most
effectively. OTOH, except if the logfile is *huge*, is the difference
large enough to matter, especially considering that the computer will
very likely have more important things to do than 'monitoring itself'?
OTOH, the source code of that was 'an interesting read'. I suggest
that 'Author: Uri Guttman' should be considered a sufficient reason to
avoid any code blindly, based on that.
------------------------------
Date: Fri, 17 Feb 2012 15:46:13 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: Using loop labels and iterating.
Message-Id: <87hayptqd6.fsf@sapphire.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mssgmbh.com> writes:
[...]
> OTOH, the source code of that was 'an interesting read'.
For instance, if PERL_IMPLICIT_SYS is not set, sysread will simply do
a read system call and that may return less data than was requested
for any number of reasons. As far as I could determine, the module
does a single sysread call for 'small files' and returns the
results. The way 'atomic updates' are implemented is known to not work
with certain filesystems because it relies on rename having barrier
semantics wrt data writes and this might not be the case (out of my
head, this will break on 'older' version of ext4, on XFS and on any
filesystem which always performs metadata updates sychronously, IOW,
UFS and FFS). There's some hardcoded support for dealing with
'Windows' textfiles in an atrociously inefficient way (by doing
single-character deletions on the read buffer which is an O(n*n)
algorithm). There's no support for dealing with any other kind of
textfiles.
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 3613
***************************************
