[26457] in Perl-Users-Digest
Perl-Users Digest, Issue: 8626 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Nov 3 09:05:31 2005
Date: Thu, 3 Nov 2005 06:05: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 Thu, 3 Nov 2005 Volume: 10 Number: 8626
Today's topics:
FAQ 6.2 I'm having trouble matching over more than one <comdog@pair.com>
Re: How to use string as two dimensional array (Anno Siegel)
Re: m//ms (was Re: s///x) <abigail@abigail.nl>
Re: m//ms <rvtol+news@isolution.nl>
Re: m//ms (Anno Siegel)
Re: m//ms <rvtol+news@isolution.nl>
Re: m//ms (Anno Siegel)
overriding 'time' and 'sleep' <samwyse@gmail.com>
Re: s///x (Anno Siegel)
Re: s///x <rvtol+news@isolution.nl>
Re: s///x <rvtol+news@isolution.nl>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 3 Nov 2005 11:03:01 +0000 (UTC)
From: PerlFAQ Server <comdog@pair.com>
Subject: FAQ 6.2 I'm having trouble matching over more than one line. What's wrong?
Message-Id: <dkcqp5$ce1$1@reader2.panix.com>
This message is one of several periodic postings to comp.lang.perl.misc
intended to make it easier for perl programmers to find answers to
common questions. The core of this message represents an excerpt
from the documentation provided with Perl.
--------------------------------------------------------------------
6.2: I'm having trouble matching over more than one line. What's wrong?
Either you don't have more than one line in the string you're looking at
(probably), or else you aren't using the correct modifier(s) on your
pattern (possibly).
There are many ways to get multiline data into a string. If you want it
to happen automatically while reading input, you'll want to set $/
(probably to '' for paragraphs or "undef" for the whole file) to allow
you to read more than one line at a time.
Read perlre to help you decide which of "/s" and "/m" (or both) you
might want to use: "/s" allows dot to include newline, and "/m" allows
caret and dollar to match next to a newline, not just at the end of the
string. You do need to make sure that you've actually got a multiline
string in there.
For example, this program detects duplicate words, even when they span
line breaks (but not paragraph ones). For this example, we don't need
"/s" because we aren't using dot in a regular expression that we want to
cross line boundaries. Neither do we need "/m" because we aren't wanting
caret or dollar to match at any point inside the record next to
newlines. But it's imperative that $/ be set to something other than the
default, or else we won't actually ever have a multiline record read in.
$/ = ''; # read in more whole paragraph, not just one line
while ( <> ) {
while ( /\b([\w'-]+)(\s+\1)+\b/gi ) { # word starts alpha
print "Duplicate $1 at paragraph $.\n";
}
}
Here's code that finds sentences that begin with "From " (which would be
mangled by many mailers):
$/ = ''; # read in more whole paragraph, not just one line
while ( <> ) {
while ( /^From /gm ) { # /m makes ^ match next to \n
print "leading from in paragraph $.\n";
}
}
Here's code that finds everything between START and END in a paragraph:
undef $/; # read in whole file, not just one line or paragraph
while ( <> ) {
while ( /START(.*?)END/sgm ) { # /s makes . cross line boundaries
print "$1\n";
}
}
--------------------------------------------------------------------
Documents such as this have been called "Answers to Frequently
Asked Questions" or FAQ for short. They represent an important
part of the Usenet tradition. They serve to reduce the volume of
redundant traffic on a news group by providing quality answers to
questions that keep coming up.
If you are some how irritated by seeing these postings you are free
to ignore them or add the sender to your killfile. If you find
errors or other problems with these postings please send corrections
or comments to the posting email address or to the maintainers as
directed in the perlfaq manual page.
Note that the FAQ text posted by this server may have been modified
from that distributed in the stable Perl release. It may have been
edited to reflect the additions, changes and corrections provided
by respondents, reviewers, and critics to previous postings of
these FAQ. Complete text of these FAQ are available on request.
The perlfaq manual page contains the following copyright notice.
AUTHOR AND COPYRIGHT
Copyright (c) 1997-2002 Tom Christiansen and Nathan
Torkington, and other contributors as noted. All rights
reserved.
This posting is provided in the hope that it will be useful but
does not represent a commitment or contract of any kind on the part
of the contributers, authors or their agents.
------------------------------
Date: 3 Nov 2005 13:21:14 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: How to use string as two dimensional array
Message-Id: <dkd2sa$4kv$1@mamenchi.zrz.TU-Berlin.DE>
Tad McClellan <tadmc@augustmail.com> wrote in comp.lang.perl.misc:
> toplicanac <info@toplice.com.remove> wrote:
>
> > How to use string as two dimensional array
[...]
> Please exercise more care in describing what you want.
>
>
> > What is easiest way to do it in Perl?
>
> This should get you started:
Another display of clairvoyance. I have corrected the erroneous line
in your code according to your follow-up.
> ---------------------
> #!/usr/bin/perl
> use warnings;
> use strict;
> use Data::Dumper;
>
> my $string = '123456abc';
> my @twoD = str2array(3, $string);
> print Dumper \@twoD;
>
>
> sub str2array {
> my($dim, $str) = @_;
>
> die "'$str' is not evenly divisible by $dim\n"
> if length($str) % $dim;
>
> my @ra;
> while ( my $row = substr $str, 0, $dim, '' ) { # corrected
> push @ra, [ split //, $row ];
> }
> return @ra;
> }
> ---------------------
As an alternative to substr, the string could be decomposed with
unpack. That returns the list of all fragments at once, so the
while loop that builds the array can be replaced by map.
sub str2array {
my($dim, $str) = @_;
die "'$str' is not evenly divisible by $dim\n"
if length($str) % $dim;
return map [ split //], unpack "(a$dim)*", $str;
}
Since we're at it, unpack can do split's job too:
return map [ unpack '(a)*', $_], unpack "(a$dim)*", $str;
This has also turned Tad's clear code into an unreadable one-line
concoction. I like to point out pack/unpack alternatives occasionally,
but I don't mean to recommend them unequivocally. Pack/unpack sends
everyone on a trip to the docs, so their use must be justified by
substantial advantages, benchmarkable or otherwise.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: 03 Nov 2005 08:13:25 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: m//ms (was Re: s///x)
Message-Id: <slrndmjhl5.jik.abigail@alexandra.abigail.nl>
Tad McClellan (tadmc@augustmail.com) wrote on MMMMCDXLVII September
MCMXCIII in <URL:news:slrndmiuip.kre.tadmc@magna.augustmail.com>:
)) Abigail <abigail@abigail.nl> wrote:
))
))
)) > Damian makes a good argument in PBP to always use /s and /m.
))
))
)) I'd better go read it.
It's a good read. One of the best Perl books published by O'Reilly.
)) > I don't think it's worth raising your finger if someone uses /s or /m
)) > on a regex where it doesn't matter.
))
))
)) To me, modifiers mean "something out of the ordinary here, pay attention!".
))
)) I feel tricked when I try to figure out why the programmer wanted dot
)) to match newline, only to find that there isn't even a dot in the pattern.
That could be, but that's _your_ problem. That's not a reason at all why
said programmer shouldn't use /s or /m. I don't expect you to program in
a style that suits me, so I don't expect you to demand that from someone
else. Your inability to understand code is something you have to solve
yourself. (Practise! ;-))
Damian's argument is that most programmers expect "." to match any
character. And for "^" and "$" to match the beginning and end of a
line. He says that if you always use /sm, you _never_ have to wonder
whether "." matches a newline or not.
Abigail
--
BEGIN {print "Just " }
INIT {print "Perl " }
END {print "Hacker\n"}
CHECK {print "another "}
------------------------------
Date: Thu, 3 Nov 2005 11:15:28 +0100
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: m//ms
Message-Id: <dkcrh0.1b8.1@news.isolution.nl>
Abigail:
> Damian's argument is that most programmers expect "." to match any
> character. And for "^" and "$" to match the beginning and end of a
> line. He says that if you always use /sm, you _never_ have to wonder
> whether "." matches a newline or not.
/sm would be a nice default. But then you need a way to disable it: /SM.
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: 3 Nov 2005 10:39:16 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: m//ms
Message-Id: <dkcpck$pkb$2@mamenchi.zrz.TU-Berlin.DE>
Dr.Ruud <rvtol+news@isolution.nl> wrote in comp.lang.perl.misc:
> Abigail:
>
> > Damian's argument is that most programmers expect "." to match any
> > character. And for "^" and "$" to match the beginning and end of a
> > line. He says that if you always use /sm, you _never_ have to wonder
> > whether "." matches a newline or not.
>
> /sm would be a nice default. But then you need a way to disable it: /SM.
As noted in another thread, PBP recommends /xsm for all regexes. That
is also the standard in Perl 6.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Thu, 3 Nov 2005 11:50:45 +0100
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: m//ms
Message-Id: <dkctn3.19o.1@news.isolution.nl>
Anno Siegel schreef:
> Dr.Ruud:
>> Abigail:
>>> Damian's argument is that most programmers expect "." to match any
>>> character. And for "^" and "$" to match the beginning and end of a
>>> line. He says that if you always use /sm, you _never_ have to wonder
>>> whether "." matches a newline or not.
>>
>> /sm would be a nice default. But then you need a way to disable it:
>> /SM.
>
> As noted in another thread, PBP recommends /xsm for all regexes. That
> is also the standard in Perl 6.
OK, great. I tend to write it as /msx, so in alphabetical order.
What is the way to make '.' not match "\n" in Perl6?
I guess Perl-5-mode, or convert to something like "[^\n]".
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: 3 Nov 2005 11:14:13 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: m//ms
Message-Id: <dkcre5$pkb$3@mamenchi.zrz.TU-Berlin.DE>
Dr.Ruud <rvtol+news@isolution.nl> wrote in comp.lang.perl.misc:
> Anno Siegel schreef:
> > Dr.Ruud:
> >> Abigail:
>
> >>> Damian's argument is that most programmers expect "." to match any
> >>> character. And for "^" and "$" to match the beginning and end of a
> >>> line. He says that if you always use /sm, you _never_ have to wonder
> >>> whether "." matches a newline or not.
> >>
> >> /sm would be a nice default. But then you need a way to disable it:
> >> /SM.
> >
> > As noted in another thread, PBP recommends /xsm for all regexes. That
> > is also the standard in Perl 6.
>
> OK, great. I tend to write it as /msx, so in alphabetical order.
I'm still hesitant about adopting this, but if I do, I'll use /xms,
following the pattern in PBP. I'd like to make it as clear as possible
just what convention I'm following.
> What is the way to make '.' not match "\n" in Perl6?
>
> I guess Perl-5-mode, or convert to something like "[^\n]".
I guess it's /[^\n]". The simplification is that the dot *always* matches
all characters, no exceptions. That won't be broken. Switching to Perl 5
for the purpose would be obscure once people have forgotten the quirks
/./ used to have.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Thu, 03 Nov 2005 13:00:31 GMT
From: Samwyse <samwyse@gmail.com>
Subject: overriding 'time' and 'sleep'
Message-Id: <PRnaf.7871$D13.6308@newssvr11.news.prodigy.com>
I'm adding a cron facility to an existing program. For testing, I'd
like to do something like this:
package Schedule::MyCron;
@ISA = ('Schedule::Cron');
our $clock = 1131030000;
sub time { $clock; }
sub sleep { $clock += shift; main::sleep 1; return; }
package main;
use Schedule::MyCron;
or I could do this:
our $Schedule::Cron::clock = 1131030000;
sub Schedule::Cron::time { $Schedule::Cron::clock; }
sub Schedule::Cron::sleep {
$Schedule::Cron::clock += shift;
main::sleep 1;
return;
}
Superficially, these seem to do the same thing (except, obviously, the
first one adds another namespace). I'd like some idea of whether there
are any subtle differences, and if so, which (if either) of these
thechniques is "better" than the others? BTW, another package that I'm
using has its own method to sleep without missing its internal events,
so the production code will eventually need to handle that as well:
package main;
my $conn = new Connection(...);
sub Schedule::Cron::sleep {
my $later = time + shift;
while (1) {
my $now = time;
return if $now >= $later;
$main::conn->process_events($later-$now);
}
}
------------------------------
Date: 3 Nov 2005 09:46:13 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: s///x
Message-Id: <dkcm95$pkb$1@mamenchi.zrz.TU-Berlin.DE>
Abigail <abigail@abigail.nl> wrote in comp.lang.perl.misc:
> Gunnar Hjalmarsson (noreply@gunnar.cc) wrote on MMMMCDXLVI September
> MCMXCIII in <URL:news:3ss54cFpe3koU1@individual.net>:
> ** Dr.Ruud wrote:
> ** > Gunnar Hjalmarsson schreef:
> ** >>Note that the /s modifier is redundant (see "perldoc perlre").
> ** >
> ** > I don't consider the /s modifier redundant. It was not needed in my
> ** > example, so maybe you meant "redundant here"?
> **
> ** Okay, redundant (or extraneous...) here. I mentioned it because people
> ** misunderstand the meaning of it all the time, and I believe one reason
> ** for that is that "perldoc perlre" - unlike e.g. "perldoc perlop" - is
> ** the only place in the docs (to my knowledge) where its meaning is
> ** properly explained.
>
>
> Damian makes a good argument in PBP to always use /s and /m.
The recommendation is to use /xms on all regular expressions, whether
the modifiers make a difference or not. It is not an invitation to add
combinations of /x, /m and /s at random.
> I don't think it's worth raising your finger if someone uses /s or /m
> on a regex where it doesn't matter. It's like complaining someone uses
> 'use warnings' on a piece of code where it didn't matter.
...or like using "sort keys ..." where "keys ..." would have done?
It really depends on what the rest of the code is like -- context. If
the general quality of the code is good, an redundant /m is, of course,
no big deal. In code that is clearly written by a beginner, it is a
sign of insecurity and/or cargo culting and ought to be pointed out.
As a reader of a piece of code, it is important to develop a feeling
for the authors competence -- how far can you trust the code. Redundant
constructs are an important indicator *against* the authors competence.
That's why it is generally a good idea to avoid them.
Anno
--
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.
------------------------------
Date: Thu, 3 Nov 2005 11:04:23 +0100
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: s///x
Message-Id: <dkcr9b.1b8.1@news.isolution.nl>
Tad McClellan:
> Dr.Ruud:
>> Anno Siegel:
>>> The changes by /x only affect the regex proper. The replacement
>>> part is still an ordinary double-quotish string.
>>
>> OK. I am still trying to think up why it was chosen to not affect the
>> replacement part.
>
> Because spaces are _supposed_ to matter when they are in a string.
There can also be spaces in the regex, and there are several ways to
present them.
I use \s where possible, and also "\x{0020}", "\x{20}", even "[ ]", "\
", depending on the context.
So I still see no reason why unprotected spaces should not be ignored in
the replacement part.
"\x{20}" and "\ " would work fine there too.
Or use a variable with a run of spaces, like $space42 = ' 'x42, and an
o-modifier.
--
Affijn, Ruud (gimme a \X)
"Gewoon is een tijger."
------------------------------
Date: Thu, 3 Nov 2005 11:40:12 +0100
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: s///x
Message-Id: <dkct9m.h0.1@news.isolution.nl>
Anno Siegel:
> Redundant constructs are an important indicator *against* the authors
> competence. That's why it is generally a good idea to avoid them.
I generally agree.
The Posting Guidelines say: "Do not provide too much information", so I
did cut down my code to an example of a few lines. But I forgot to toss
the s-modifier.
And now that I have inserted the m- and x-modifiers in all the
appropriate places (I had read that chapter of PBP before but had forgot
about it), I won't even have to do that anymore. :)
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
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 V10 Issue 8626
***************************************
