[17893] in Perl-Users-Digest
Perl-Users Digest, Issue: 53 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jan 12 21:05:37 2001
Date: Fri, 12 Jan 2001 18:05:08 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <979351508-v10-i53@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Fri, 12 Jan 2001 Volume: 10 Number: 53
Today's topics:
[OT] Re: Getting files off remote servers <joe+usenet@sunstarsys.com>
Re: Ada feature borrowed for Perl?? (Mark Jason Dominus)
Re: Ada feature borrowed for Perl?? (Abigail)
Delay in accessing web pages on intranet. Looking for r (FDShah)
Re: Getting files off remote servers <iltzu@sci.invalid>
Help this newbie learn continued. <hafateltec@hotmail.com>
Re: Help: Installation Failed <qiuminh@my-deja.com>
Re: HTTP::Request encoding query <iltzu@sci.invalid>
Re: HTTP::Request encoding query <joe+usenet@sunstarsys.com>
Re: HTTP::Request encoding query <flavell@mail.cern.ch>
Re: Jobs: Senior Software Engineer (David H. Adler)
Re: Jobs: Senior Software Engineer (Martien Verbruggen)
Re: match from the end or match the last (Martien Verbruggen)
Re: Perl script <comdog@panix.com>
Re: Search scipt egwong@netcom.com
Re: Switch to Linux (Abigail)
Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 12 Jan 2001 19:01:01 -0500
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: [OT] Re: Getting files off remote servers
Message-Id: <m37l402ude.fsf_-_@mumonkan.sunstarsys.com>
Ilmari Karonen <iltzu@sci.invalid> writes:
> I just recently had a piece of spam evade my filters for the first
> time in a long while. It was addressed to "perl@itz.pp.sci.fi". I
> still haven't heard back from the maintainers of the relay they used
> -- I guess I ought to see if it's still open, and nominate them for
> the RBL if it is.
Don't bother - someone already did that for you :) MAPS and ORBS
are liberating in that way (the diligence of a few benefits us all).
--
Joe Schaefer
------------------------------
Date: Fri, 12 Jan 2001 23:48:24 GMT
From: mjd@plover.com (Mark Jason Dominus)
Subject: Re: Ada feature borrowed for Perl??
Message-Id: <3a5f97c8.5813$2ff@news.op.net>
In article <979339185.16527@itz.pp.sci.fi>,
Ilmari Karonen <usenet11334@itz.pp.sci.fi> wrote:
>>> push(@ERRORS, "You omitted your age!"), last
>>> if param('age') eq "";
>>> push(@ERRORS, "Your age should be a number!"), last
>>> if param('age') =~ /\D/;
>>
>>Very interesting. I would have considered that 'spaghetti code', and
>>I would have been embarrassed to write it. (That is not intended as a
>>criticism of any kind.)
>
>Now *that's* funny.. I can see how, it *is* repetitive, but then so
>is the original too.. And there isn't really much common code in the
>statements to factor out, which is IMHO a key criteria for spaghetti.
For me, the key requirement of spaghetti is convoluted control
flow---hence the name.
Repetition doesn't enter into it.
>Yes. For some reason I like it. It's.. less noisy, for one thing.
>And it lets me factor common statement parts out of the conditional,
>something even statement modifiers can't do.
I guess
$ua->agent(do { if (defined $opt_A) {
$opt_A;
} elsif ($opt_m) {
'Mozilla/3.04 (X11; I; Linux 2.2.12 i586)'
} else {
"Site Copier ($ADDRESS)" . $ua->agent;
}
});
does not appeal to you? (Joke! Joke!)
>A keyword like "then" as a low-precedence scalar comma would be nice.
Or even better, it could do nothing at all!
$title = $_, then next LINE if !$title and /\S/;
push(@bad_urls, $url), then next URL unless $resp->is_success;
push(@QUEUE, links($url, $resp->content)),
then ++$HTML
if $resp->content_type eq 'text/html';
That is very nice. I don't know if I would use it, but it's nice.
A meaningless 'then' would also have the benefit that
if (EXPR) then BLOCK
would no longer be a syntax error.
--
@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2)+=$f=!fork;map{$P=$P[$f|ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];sleep rand(2)if/\S/;print
------------------------------
Date: 12 Jan 2001 23:56:41 GMT
From: abigail@foad.org (Abigail)
Subject: Re: Ada feature borrowed for Perl??
Message-Id: <slrn95v6dp.5p0.abigail@tsathoggua.rlyeh.net>
Mark Jason Dominus (mjd@plover.com) wrote on MMDCXCI September MCMXCIII
in <URL:news:3a5f2d53.4e2e$30a@news.op.net>:
:) In article <978374927.4396@itz.pp.sci.fi>,
:) Ilmari Karonen <usenet11323@itz.pp.sci.fi> wrote:
:) >In article <3a50aee2.3873$2eb@news.op.net>, Mark Jason Dominus wrote:
:) >>
:) >>With 'elsif' being the 'one you use every day'.
:) >
:) >Hey, you're right! Though that's just because the only script that
:) >"grep -l elsif perl/*" turned up is the one I use to post to Usenet.
:) >
:) >I understand the point of having "elsif", but in my experience it's a
:) >particularly rarely needed feature, unless you're fond of spaghetti
:) >code.
:)
:) Interesting. I wonder how you manage to avoid it?
:)
:) Here are some elsifs I wrote in recent programs:
:)
:) A.
:) if (param('age') eq "") {
:) push @ERRORS, "You omitted your age!";
:) } elsif (param('age') =~ /\D/) {
:) push @ERRORS, "Your age should be a number!";
:) }
:)
:) I think this is the prototypical example. You cannot use a dispatch
:) table here.
Sometimes, I would write A. as:
push @ERRORS => param ('age') eq "" ? "You omitted your age!"
: param ('age') =~ /\D/ ? "Your age should be a number!"
: ();
This makes it clear all the cases have a common factor.
:) C.
:)
:) if (param()) {
:) # (update database)
:) } elsif (defined(my $pid = get_person())) {
:) # (display information about database record #$pid)
:) } else {
:) # (display form)
:) }
A (relative) easy way to avoid elsif is the use of a bare block:
{ if (param ()) {
# update database
last;
}
if (defined (my $pid = get_person ())) {
# display information about database record #$pid
last;
}
# display form
}
I won't claim it leads to clearer code though.
:)
:) D.
:)
:) sub get_person {
:) if (my $pi = path_info()) {
:) $pi =~ tr{/}{}d;
:) return $pi eq '' ? undef : $pi;
:) } elsif (defined(my $p = param('person'))) {
:) return $p;
:) } else {
:) return;
:) }
:) }
:)
:) Here I might have used something more like
:)
:) return path_info() || param('person')
:)
:) except that the logic is just a little too complicated---there is no
:) way to get the defined() test or the tr///d into the right place if
:) you do that. However, I could have replaced the elsif:
:)
:) sub get_person {
:) if (my $pi = path_info()) {
:) $pi =~ tr{/}{}d;
:) return $pi eq '' ? undef : $pi;
:) } else
:) return param('person');
:) }
:) }
:)
:) This shortens the code, which is good, but it is no longer clear that
:) the possibly undefined return value is not an oversight. I think the
:) original code makes the intention clearer.
But because you return in each clause, there's no need for any else or
elsif:
sub get_person {
if (my $pi = path_info ()) {
$pi =~ tr {/}{}d;
return $pi eq "" ? undef : $pi;
}
if (defined (my $p = param ('person'))) {
return $p;
}
return;
}
Or even (if param ('person') returns an empty list if non-existant):
sub get_person {
if (my $pi = path_info ()) {
$pi =~ tr {/}{}d;
return $pi eq "" ? undef : $pi;
}
param ('person');
}
:) E.
:) my $resp = $ua->request($req);
:) if (! $resp->is_success) {
:) push @bad_urls, $url;
:) } elsif ($resp->content_type eq 'text/html') {
:) push @QUEUE, links($url, $resp->content);
:) ++$HTML;
:) }
:)
:) This is another typical example. How do you write this sort of logic
:) without 'elsif'? It seems perfectly natural to me, and it even reads
:) the way I would explain the logic in English: "If the request is
:) unsuccessful, put the url into the list of bad urls; or else if the
:) request yielded HTML, get the links from it and put them in the
:) queue."
Without claiming to have better code, a way to write this without elsif:
my $resp = $ua->request($req);
if ($resp->is_success) {
push (@QUEUE, links($url, $resp->content)), ++ $HTML if
$resp -> content_type eq 'text/html'
}
else {
push @bad_urls, $url;
}
:) H.
:)
:) if (defined $opt_A) {
:) $ua->agent($opt_A);
:) } elsif ($opt_m) {
:) $ua->agent('Mozilla/3.04 (X11; I; Linux 2.2.12 i586)');
:) } else {
:) $ua->agent("Site Copier ($ADDRESS)" . $ua->agent);
:) }
$ua -> agent (defined $opt_A ? $opt_A
: $opt_m ? 'Mozilla/3.04 (X11; I; Linux 2.2.12 i586)'
: "Site Copier ($ADDRESS)" . $ua->agent);
:) Looking these over, I don't draw any especially enlightening
:) conclusions about my usage patterns for 'elsif'. But I find myself
:) more rurpsied than ever that you don't use it. How would you have
:) written (E) or (I) for example?
While I do use elsif, I don't use it too often. For me, "elsif" is
just a shorthand for "else if", and in other languages, I try to
avoid to many nested ifs. OTOH, I don't shy away from chained ?:'s
and that isn't any better than elsif.
Perl has many control constructs; I don't think you can say there is
one you can't program without turning your code into a mess.
Abigail
--
perl5.004 -wMMath::BigInt -e'$^V=Math::BigInt->new(qq]$^F$^W783$[$%9889$^F47]
.qq]$|88768$^W596577669$%$^W5$^F3364$[$^W$^F$|838747$[8889739$%$|$^F673$%$^W]
.qq]98$^F76777$=56]);$^U=substr($]=>$|=>5)*(q.25..($^W=@^V))=>do{print+chr$^V
%$^U;$^V/=$^U}while$^V!=$^W'
------------------------------
Date: 13 Jan 2001 00:55:07 GMT
From: fdshah@aol.com (FDShah)
Subject: Delay in accessing web pages on intranet. Looking for reasons...
Message-Id: <20010112195507.23765.00000003@ng-fz1.aol.com>
Curious Newbie Question:
Does anybody know why there's such a long delay when I access my web pages in
the root directory of PWS using http://mycomputername/myfilename? I've observed
this typically happens when I'm connected to the internet.
Of course, when I use http://localhost/myfilename or
http://127.0.0.1/myfilename, there's no delay.
I have PWS 4.0 installed on my computer for testing & design for several
websites and I am not connected to any local networked computers.
Also any information on the importance & functions of http://localhost or the
ip 127.0.0.1 would be appreciated.
Thanks,
Dipesh ;-)
fdshah@aol.com
------------------------------
Date: 12 Jan 2001 23:32:12 GMT
From: Ilmari Karonen <iltzu@sci.invalid>
Subject: Re: Getting files off remote servers
Message-Id: <979340852.19283@itz.pp.sci.fi>
In article <t5uihrb1ojca30@corp.supernews.com>, Chris Stith wrote:
>Programming is a lot like fire, talk radio, guns, or what the
>occultists say about magic. It is not the tool that is good or evil,
>only the person using it. That is to say, you can use a tool towards
>benevolent ends or towards malevolent ends, and can use it in
>benevolent ways or malevolent ways to reach those ends, but the tools
>themselves are blameless.
In some sense that is quite true indeed. Yet in others.. let me give
an example: A major reason, why spam isn't even more of a problem than
it already is, is that no-one capable of actually writing *good* tools
for spamming and address harvesting feels any inclination to do so.
Yes, we do have Mail::Bulkmail, but I haven't really heard of any of
the actual spam tools using it. Mostly because you'd still need a
programmer to write the user interface for the canned tool.
It's actually quite amazing. There are well written viruses out
there, but no smart address harvesters. How do I know it? First,
because I haven't heard of any, but also because I haven't *ever*
encountered any myself.
There are address harvesters that search the WWW. There are those
that grep news overview lists. Despite widespread paranoia, I've
never heard of or witnessed an address being harvested from the body
of a Usenet post, or from any other header except "From:".
And at least most of the news harvesters seem to use broken regexen
for finding the addresses. Ironically, I know this because using
"iltzu@sci.fi.invalid" still resulted in spam to "iltzu@sci.fi". But
I've also heard reports that any address with punctuation other than
. or _ in it is virtually never harvested intact.
I just recently had a piece of spam evade my filters for the first
time in a long while. It was addressed to "perl@itz.pp.sci.fi". I
still haven't heard back from the maintainers of the relay they used
-- I guess I ought to see if it's still open, and nominate them for
the RBL if it is.
--
Ilmari Karonen - http://www.sci.fi/~iltzu/
"If that's a reasonable definition, I prefer unreasonable ones."
-- Simon van Dongen in rec.arts.sf.science
------------------------------
Date: Sat, 13 Jan 2001 09:45:05 +1000
From: "Mike McPherson" <hafateltec@hotmail.com>
Subject: Help this newbie learn continued.
Message-Id: <93o4vk$6q7$1@brokaw.wa.com>
Ok, I want to take this program a couple of steps further now.
I have modified the code into two sub routines, added use strict as
suggested, added use vars qw/$VERSION/ for turning this into an actual
program in the future.
#!/usr/bin/perl -w
# Little snip I created to convert ASCII to Characters and vice-versa.
use strict; #Helgi Briem suggested I add the strict mod
use vars qw /$VERSION/;
#used by Make to get version information
($VERSION) = '$Revision: 1.0 $' =~ /([\d.]+)/;
#declare variables
my ($what, $ascii, $char, $convert_char, $convert_ascii);
#starts program
&checkargs;
#makes sure that a variable was added on the command line
sub checkargs {
if (@ARGV){ #Thanks to Wyzelli from comp.lang.perl.misc
$what = (shift @ARGV);
&converter;
}
else {
die "\nUsage ASCII or CHAR: $!\n";
}
}
#performs the conversion required
sub converter {
if ($what eq 'ASCII') {
print "\nOption ASCII\n";
print "\nPlease enter the ASCII Number you wish to convert to a
character --->";
$ascii = <STDIN>;
$convert_ascii = chr($ascii);
print "\nYour conversion is chr($ascii) equals $convert_ascii\n";
}
elsif ($what eq 'CHAR') {
print "\nOption CHAR\n";
print "\nPlease enter the Character you wish to convert to ASCII --->";
$char = <STDIN>;
$convert_char = ord($char);
print "\nYour conversion is $char equals $convert_char\n";
}
elsif ($what eq 'v') {
print "\nVersion $VERSION January 13, 2001\n";
}
}
Now the original program only accepts input via the command line. Now I
would like it to
1. Accept input during runtime.
2. Have a escape parameter.
3. After one operation conversion is complete continue unless the escape
parameter has been given.
I have tried numerous things to accomplish above but to no avail. Again,
thanks in advance for any suggestions/help/ect...
Mike McPherson
------------------------------
Date: Fri, 12 Jan 2001 23:13:35 GMT
From: Haiyan Wang <qiuminh@my-deja.com>
Subject: Re: Help: Installation Failed
Message-Id: <93o32p$9vj$1@nnrp1.deja.com>
In article <3a5f22f2.266480809@news.itn.is>,
helgi@NOSPAMdecode.is wrote:
> On Fri, 12 Jan 2001 04:42:44 GMT, Haiyan Wang
> <qiuminh@my-deja.com> wrote:
>
> >I download ActivePerl-5.6.0.623-MSWin32-x86-multi-thread.zip and try
> >to install it. It gives me an error Internal Error 2336. 5,
> >C:\WINNT\Installer\
> >
> >The OS is Win2000 Workstation.
>
> My guess is that you don't have MS Installer, although
> it shoudl come standard with Win2K.
> This product is required to install the
> ActivePerl-5.6.0.623-MSWin32-x86-multi-thread,msi
> file contained in your zip file.
>
> You can get it at:
>
http://download.microsoft.com/download/platformsdk/wininst/1.0/WIN98/EN-
US/IntelSDK.msi
>
> Regards,
> Helgi Briem
>
Helgi
Thanks for help.
I download the package and installed it. But it still doesn't work. It
just stops at "Status: Registering Product".
One thing I notice is that those *.msi files do not have an icon
associated with them. Does that mean WINNT has not been installed
correct?
Thanks
QM
Sent via Deja.com
http://www.deja.com/
------------------------------
Date: 12 Jan 2001 23:52:51 GMT
From: Ilmari Karonen <iltzu@sci.invalid>
Subject: Re: HTTP::Request encoding query
Message-Id: <979342462.21913@itz.pp.sci.fi>
In article <Pine.LNX.4.30.0101121932210.13422-100000@lxplus003.cern.ch>, Alan J. Flavell wrote:
>On Fri, 12 Jan 2001 iain_hogg@my-deja.com wrote:
>
>> The cgi-bin script I'm trying to work with (which I can't change) does not
>> unencode its input i.e. change '%7C' back to '|',
>
>Then that's your real problem, but it has nothing to do with
>programming in Perl. It would be more on-topic for a group with CGI
>in its name.
Hardly, IMHO, unless the OP is planning to write his own script
instead of accessing an existing one.
>You seem blithely unaware that there is a published interworking
>specification, and that you are using a script that doesn't follow
>that specification. On that basis, there could well be a lot of other
>things wrong with the script, including security exposures.
I considered a similar reply, but reading the post more carefully
suggested the the OP was trying to access an existing, broken, service
that he has no control over.
Now, if I were in the OP's situation, I would certainly write to the
maintainers of the broken script and tell them to fix it. But it's
quite possible he has already done that, and they just don't care.
On a completely unrelated issue, I would actually suggest that
HTTP::Request should accept anything given to it as an URI, rather
than trying to fix encoding problems after they've already happened.
RFC 2396, section 2.4.2, has something to say about this:
Normally, the only time escape encodings can safely be made is when
the URI is being created from its component parts; each component
may have its own set of characters that are reserved, so only the
mechanism responsible for generating or interpreting that component
can determine whether or not escaping a character will change its
semantics.
No, it doesn't address the issue directly. But it does point out that
any encoding done after the URI has been composed should be pointless,
and any cases where it isn't should be considered broken.
--
Ilmari Karonen - http://www.sci.fi/~iltzu/
"Of course, it's filled up with rolls of toilet paper (bought in bulk from
Costco) and leaky inflatable mattresses that we really ought to throw away,
but it's a linen closet." -- Dorothy J. Heydt in rec.arts.sf.composition
------------------------------
Date: 12 Jan 2001 19:20:28 -0500
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: HTTP::Request encoding query
Message-Id: <m33deo2tgz.fsf@mumonkan.sunstarsys.com>
Ilmari Karonen <iltzu@sci.invalid> writes:
(rest of excerpt from RFC 2396 added)
2.4.2. When to Escape and Unescape
A URI is always in an "escaped" form, since escaping or
unescaping a completed URI might change its semantics.
>> Normally, the only time escape encodings can safely be made is when
>> the URI is being created from its component parts; each component
>> may have its own set of characters that are reserved, so only the
>> mechanism responsible for generating or interpreting that component
>> can determine whether or not escaping a character will change its
>> semantics.
>
> No, it doesn't address the issue directly.
Yes it does!
2.4.3. Excluded US-ASCII Characters
...
Other characters are excluded because gateways and other
transport agents are known to sometimes modify such characters,
or they are used as delimiters.
unwise = "{" | "}" | "|" | "\" | "^" | "[" | "]" | "`"
Data corresponding to excluded characters must be escaped
in order to be properly represented within a URI.
...
I'd say that's a pretty direct statement that "|" is forbidden
in a URI.
> But it does point out that any encoding done after the URI has
> been composed should be pointless, and any cases where it isn't
> should be considered broken.
Which is why the RFC makes no effort to define an "escaped" URI.
URI's are *always* in escaped form.
--
Joe Schaefer
------------------------------
Date: Sat, 13 Jan 2001 01:17:12 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: HTTP::Request encoding query
Message-Id: <Pine.LNX.4.30.0101130112150.13422-100000@lxplus003.cern.ch>
On 12 Jan 2001, Ilmari Karonen wrote:
> In article <Pine.LNX.4.30.0101121932210.13422-100000@lxplus003.cern.ch>, Alan J. Flavell wrote:
> >On Fri, 12 Jan 2001 iain_hogg@my-deja.com wrote:
> >
> >> The cgi-bin script I'm trying to work with (which I can't change) does not
> >> unencode its input i.e. change '%7C' back to '|',
> >
> >Then that's your real problem, but it has nothing to do with
> >programming in Perl. It would be more on-topic for a group with CGI
> >in its name.
>
> Hardly, IMHO, unless the OP is planning to write his own script
> instead of accessing an existing one.
OK, it's a fair call. I still say the _real_ problem is that he's
working with a broken script, but as you say, it might be outside of
his control.
And since in this specific case the client software _is_ under his
control, I can see that I'd taken the wrong line with the original
posting. My apologies.
------------------------------
Date: 12 Jan 2001 23:31:14 GMT
From: dha@panix2.panix.com (David H. Adler)
Subject: Re: Jobs: Senior Software Engineer
Message-Id: <slrn95v4u2.b9i.dha@panix2.panix.com>
On Fri, 12 Jan 2001 13:48:35 -0500, brian d foy <comdog@panix.com> wrote:
>i just convinced the company to open a new york office. that solved
>the location problem. someday new york will not only be the Center
>of the Universe but the Center of the Perl Universe as well ;)
It already is. :-)
dha
--
David H. Adler - <dha@panix.com> - http://www.panix.com/~dha/
"If you want a real optimist, look up Ray Bradbury. Guy's nuts.
He actually likes people." - David Brin
------------------------------
Date: Sat, 13 Jan 2001 11:28:33 +1100
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: Jobs: Senior Software Engineer
Message-Id: <slrn95v89h.50v.mgjv@martien.heliotrope.home>
On Fri, 12 Jan 2001 17:19:29 -0000,
Chris Stith <mischief@velma.motion.net> wrote:
>
> Some people here might not
> even mind being emailed job offers directly to them, although I'm
> sure some would.
It depends on the email. If the email is clearly a personal one, written
by a real life person, and it is clear that what they offer fits what I
do, and who and where I am, then it is clear enough to me that they've
done their homework. That's a normal practice for employment agencies
and head hunters. You put a feeler out, investigate, then approach the
person. Whether that's by email or phone is hardly relevant. I didn't
ask for the email, but that doesn't mean it's UCE/UBE.
And that's where the offensive bit comes in. I regularly get email (most
of which get filtered away by procmail), of employment agencies who, in
my view, have undiscriminately spammed every valid email address on
clp.misc or clp.modules. A dead giveaway for me normally is 'Great job
opportunity in Dinkyville, Arkansas.' Anyone who'd personally write an
email to me would notice that my location is very unlikely to be close
enough to the USA to be really interested in that job. Needless to say,
all this email does is grow the procmail filter.
Occasionally, however, I do get a genuine email, one that didn't come
out of a machine. I respond to these.
It's not the U in UBE that pisses people off. It's the B.
Martien
--
Martien Verbruggen |
Interactive Media Division |
Commercial Dynamics Pty. Ltd. | "Mr Kaplan. Paging Mr Kaplan..."
NSW, Australia |
------------------------------
Date: Sat, 13 Jan 2001 11:09:49 +1100
From: mgjv@tradingpost.com.au (Martien Verbruggen)
Subject: Re: match from the end or match the last
Message-Id: <slrn95v76d.50v.mgjv@martien.heliotrope.home>
On 12 Jan 2001 10:59:19 -0500,
Joe Schaefer <joe+usenet@sunstarsys.com> wrote:
> mgjv@tradingpost.com.au (Martien Verbruggen) writes:
>
>> On Fri, 12 Jan 2001 12:29:47 +0800,
>> John Lin <johnlin@chttl.com.tw> wrote:
>> > Dear all,
>> >
>> > In regular expression, is there a modifier or any idiomic way to
>> > match from the end (backward)? Let's say if the modifier is 'b', then
>> >
>> > ($_ = 'xyzxyzxyz') =~ s/y/Y/b; print;
>> >
>> > results in:
>> >
>> > 'xyzxyzxYz' instead of 'xYzxyzxyz'
>>
>> Is the question really something like : How do I only change the _last_
>> occurence of a match with s///
>>
>> Regular expressions in Perl always match forward. But in this particular
>> case you can make use of the fact that quantifiers, by default, are
>> greedy:
>>
>> s/(.*)y/Y/;
> ^
> ITYM s/(.*)y/$1Y/ here. Here's a harder case to consider (using above "b")
Yep, that's what I meant :)
> ($_ = "xyz3xyz3343 A" ) =~ s/\d+//b; print;
>
> results in "xyz3xyz A".
Hmm... greedy and longest match competing for the digits..
> Short of reversing the string, the only regexp I can think of for this
> one is
>
> s/\d+(?=\D*$)//;
Yes, or more closely related to the solution given above for the other
string:
s/(.*\D)\d+/$1/;
which of course will start failing when there is nothing in front of the
last string of digits, something which yours is immune to.
> s/y(?=[^y]*$)/Y/;
>
>> PS. Interestingly enough, I couldn't find anything about this in the
>> FAQ. If no one knows any documentation that talks about this, I might
>> write one and submit it.
>
> Within the "s///g" description, there is an anectodal remark in
> I'm not aware of a general strategy for doing this; it could be plain-old
> ignorance though. It will be enlightening to read the documentation
> you come up with - equidistribution of greed is always a topic of
> interest ;)
Thanks for the pointers. I'll take your post, mine, and the
documentation entries, and see if I can come up with something that
could go in the FAQ. It looks like it could be a rather lengthy entry :)
I think the conclusions will be something like: reversing the string is
the best general purpose way. Any time you need performance, or can say
something special about your data, you may be able to use one of the
other ways of dealing with it. If you need performance without being
able to use a special case, you'll have to use lookaheads to anchor your
regex to the end of the string.
Martien
--
Martien Verbruggen | My friend has a baby. I'm writing
Interactive Media Division | down all the noises the baby makes so
Commercial Dynamics Pty. Ltd. | later I can ask him what he meant -
NSW, Australia | Steven Wright
------------------------------
Date: Fri, 12 Jan 2001 18:22:58 -0500
From: brian d foy <comdog@panix.com>
Subject: Re: Perl script
Message-Id: <comdog-017766.18225812012001@news.panix.com>
In article <3A5F6246.D2887961@cicada-semi.com>, Brent Dinicola
<brentd@cicada-semi.com> wrote:
> brian d foy wrote:
>
> > In article <3A5F5B9A.D92BE396@cicada-semi.com>, Brent Dinicola
> > <brentd@cicada-semi.com> wrote:
> > > Has anyone out there written a script that will check for something in a
> > > log
> > > say.. in the same hour the script is being run and if it finds it..
> > > email someone?
> > i've made several such scripts. is there another question?
> PS. and if so.. would anyone mind showing it to me.. or emailing?
well, they are all very specific to the particular task. if you
could read my source for them then you have probably been using
Perl long enough to already know how to do it already.
which part of the problem is holding up progress?
--
brian d foy <comdog@panix.com>
no longer for hire ;)
------------------------------
Date: Fri, 12 Jan 2001 23:25:37 GMT
From: egwong@netcom.com
Subject: Re: Search scipt
Message-Id: <RnM76.3326$J%.351005@news.flash.net>
stevec <stevec@ntlworld.com> wrote:
> Has anyone worked on or knows of a perl (or any other) script that will
> search other web sites and compare prices, amalgamate them and list the
> different prices on a web page?
% perl -MLWP::Simple -e 'getprint "http://bqueen.pricewatch.com/search/search.idq?cr=ibm"'
although you might want to dig around and refine the search parameters.
------------------------------
Date: 13 Jan 2001 00:08:26 GMT
From: abigail@foad.org (Abigail)
Subject: Re: Switch to Linux
Message-Id: <slrn95v73q.5p0.abigail@tsathoggua.rlyeh.net>
wish_was_a_newbie@db-networks.com (wish_was_a_newbie@db-networks.com)
wrote on MMDCXCI September MCMXCIII in <URL:news:cbnu5t8187tippd2kpj0q3o516k3lgd3i5@4ax.com>:
;; Hi,
;;
;; I am both a Perl and Linux newbie.
;;
;; I have some perl scripts that work under Win98. I installed RedHat 6.2
;; with Perl. Perl "works."
;;
;; The scripts use LWP::UserAgent. I downloaded:
;; perl-libwww-perl-5.43-2.i386.rpm.
;;
;; I used rpm to "install" it. The script still does not compile.
;;
;; Where can I find the instructions on how to properly install the LWP::
;; module?
In the README file in the tarball of the LWP bundle, which you can get
from your local CPAN mirror.
Most CPAN modules require you to unpack the tarball, cd to the new directory
and then do:
perl Makefile.PL
make
make test
su perladmin -c 'make install'
Abigail
--
BEGIN {my $x = "Knuth heals rare project\n";
$^H {integer} = sub {my $y = shift; $_ = substr $x => $y & 0x1F, 1;
$y > 32 ? uc : lc}; $^H = hex join "" => 2, 1, 1, 0, 0}
print 52,2,10,23,16,8,1,19,3,6,15,12,5,49,21,14,9,11,36,13,22,32,7,18,24;
------------------------------
Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 16 Sep 99)
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: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.
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 53
*************************************
