[9852] in Perl-Users-Digest
Perl-Users Digest, Issue: 3445 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Aug 14 10:17:26 1998
Date: Fri, 14 Aug 98 07:12:58 -0700
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, 14 Aug 1998 Volume: 8 Number: 3445
Today's topics:
Substitution (Ollie Cook)
Re: Substitution <perlguy@inlink.com>
Re: Substitution (Alastair)
Re: Substitution <jdporter@min.net>
Re: Substitution <jdf@pobox.com>
Re: Substitution (Matthew Bafford)
Re: SW Eng Mgr - Cutting Edge Pre IPO <perlguy@inlink.com>
Re: What is the purpose of Perl <jdporter@min.net>
Re: X-file (?=...), case postponed. (Ronald J Kimball)
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 14 Aug 1998 08:51:23 GMT
From: oliver.REMOVE.cook@bigfoot.DELETE.com (Ollie Cook)
Subject: Substitution
Message-Id: <35d8fa84.3776959@news.ukonline.co.uk>
I'm trying to map all forward-slashes in a scalar to underscores.
Looking at my Perl book, Learning Perl, published by O'Reilly I
thought the code
$file =~ s/\//_/;
would do the trick, but this only does the first forwardslash and
leaves the rest. I'm obviously doing something very stupid. A typical
value for $file is "/ollie/pf/index.shtml"
Thanks in advance,
Ollie
----
Oliver COOK, Web Site Designer for
Premiere Web Designs - Http://Www.Premiere.Uk.Com/
+
Webmaster of The Audio-Visual Archive
* over 900 images and 700 sounds, free
* Http://Www.Premiere.Uk.Com/ava/
------------------------------
Date: Fri, 14 Aug 1998 11:37:38 GMT
From: Brent Michalski <perlguy@inlink.com>
Subject: Re: Substitution
Message-Id: <35D42182.A75084E8@inlink.com>
Ollie Cook wrote:
>
> I'm trying to map all forward-slashes in a scalar to underscores.
> Looking at my Perl book, Learning Perl, published by O'Reilly I
> thought the code
>
> $file =~ s/\//_/;
>
> would do the trick, but this only does the first forwardslash and
> leaves the rest. I'm obviously doing something very stupid. A typical
> value for $file is "/ollie/pf/index.shtml"
Ollie, you had it SOOOOO close. You missed a "modifier" that goes on
the end. Change it to:
$file =~ s/\//_/g;
^
The "g" means GLOABLLY do the search and replace...
Good luck!
Brent
------------------------------
Date: 14 Aug 1998 12:49:05 GMT
From: alastair@psoft.co.uk (Alastair)
Subject: Re: Substitution
Message-Id: <6r1bo1$7dt@handupme.avid.com>
Ollie Cook <oliver.REMOVE.cook@bigfoot.DELETE.com> wrote:
>I'm trying to map all forward-slashes in a scalar to underscores.
>Looking at my Perl book, Learning Perl, published by O'Reilly I
>thought the code
>
>$file =~ s/\//_/;
>
>would do the trick, but this only does the first forwardslash and
>leaves the rest. I'm obviously doing something very stupid. A typical
>value for $file is "/ollie/pf/index.shtml"
I think you'll need to add the 'global' option 'g' i.e.
$file =~ s/\//_/g;
See perlop and perlre. Hope that helps.
--
Alastair
Avid Effects
alastair@psoft.co.uk
------------------------------
Date: Fri, 14 Aug 1998 09:10:10 -0400
From: John Porter <jdporter@min.net>
Subject: Re: Substitution
Message-Id: <35D43732.5D65@min.net>
Brent Michalski wrote:
> Ollie Cook wrote:
> > $file =~ s/\//_/;
> $file =~ s/\//_/g;
In addition to Brent's correct answer, I would like
to add a suggestion. You can maybe make your thing
more readable by using something other than slashes
in the s/// expression. For example:
s,/,_,g;
s#/#_#g;
s(/){_}g;
--
John Porter
------------------------------
Date: 14 Aug 1998 09:28:23 -0500
From: Jonathan Feinberg <jdf@pobox.com>
To: oliver.REMOVE.cook@bigfoot.DELETE.com
Subject: Re: Substitution
Message-Id: <yasriqns.fsf@mailhost.panix.com>
oliver.REMOVE.cook@bigfoot.DELETE.com (Ollie Cook) writes:
> $file =~ s/\//_/;
Someone else has already given you the answer, so I'll add a stylistic
note. When a forward slash character is significant in your pattern,
you should use a different regex delimiter. Here are a couple of
examples:
s{/}{_}g; #I like this one
s!/!_!g; #Some prefer this
--
Jonathan Feinberg jdf@pobox.com Sunny Brooklyn, NY
http://pobox.com/~jdf/
------------------------------
Date: Fri, 14 Aug 1998 14:04:11 GMT
From: dragons@scescape.net (Matthew Bafford)
Subject: Re: Substitution
Message-Id: <MPG.103e0536bbfcbcd7989697@news.scescape.net>
In article <35d8fa84.3776959@news.ukonline.co.uk> on Fri, 14 Aug
1998 08:51:23 GMT, Ollie Cook (a) felt the following information
to be of use:
> I'm trying to map all forward-slashes in a scalar to underscores.
> Looking at my Perl book, Learning Perl, published by O'Reilly I
> thought the code
>
> $file =~ s/\//_/;
>
> would do the trick, but this only does the first forwardslash and
> leaves the rest. I'm obviously doing something very stupid. A typical
> value for $file is "/ollie/pf/index.shtml"
>
Hey Ollie!
Read Brent's description of how to get the s///; to work. I come
with an alternative... :)
If all you want to do is change letter for letter, tr///; is
_much_ better (ie faster).
To do that, you would change your above code to:
$file =~ tr|/|_|;
To see how much faster it is, consider the following code:
#!/usr/bin/perl -w
use Benchmark;
use strict;
timethese(100_000, {
's///g' => sub{$_='/////////'; s|/|_|g;},
'tr///' => sub{$_='/////////'; tr|/|_|;}
}
);
__END__
Results in:
Benchmark: timing 100000 iterations of s///g, tr...
s///g: 6 secs ( 5.48 usr 0.00 sys = 5.48 cpu)
tr///: 2 secs ( 1.44 usr 0.00 sys = 1.44 cpu)
So, as you can see, tr is _much_ faster! :)
Hope this helps!
--Matthew
------------------------------
Date: Fri, 14 Aug 1998 11:49:50 GMT
From: Brent Michalski <perlguy@inlink.com>
Subject: Re: SW Eng Mgr - Cutting Edge Pre IPO
Message-Id: <35D4245E.FA680EF1@inlink.com>
careers_zland_com@my-dejanews.com wrote:
>
> ZLand is the #1 provider of web-based ERP solutions for small and mid-sized
... Sure, I believe you ...
> ZLand is currently recruiting for two exceptional SOFTWARE ENGINEERING
> MANAGERS.
> Both will be faced with an infinite number of challenges as they
^^^^^^^^
I'd rather have a finite number of challenges, infinite challenges tend
to overwhelm mortals...
> Excellent GROWTH opportunity as we double the size of our Engineering
> department in the immediate future.
Between the lines: They currently have 2, and are hiring 2 more...
>Significant STOCK OPTIONS upon hire.
Between the lines: The pay sucks, but we'll give you worthless stock to
make up for it.
> KEY WORDS: Lotus Notes / Domino / CORBA / Java / C++ / VB / Delphi / IIOS /
> OOA / OOD / Oracle
NO PERL!!! Obviously they are going nowhere with this company :-)
------------------------------
Date: Fri, 14 Aug 1998 09:28:31 -0400
From: John Porter <jdporter@min.net>
Subject: Re: What is the purpose of Perl
Message-Id: <35D43B7F.53E7@min.net>
I'm sorry. I can't help myself.
I hope someone out there is enjoying these.
# Rev 21:6
/\AI.*I\Z/;
BEGIN { $Jah; }
END { $Jah; }
# I Cor 13:11
@Child::ISA = @Man::ISA = qw(Person);
$roman = new Child 'Saul';
$roman->talk;
$roman->think;
$roman->reason;
$roman = new Man 'Paul';
# 1 Cor 13
sub Person::speak {
my $self = shift;
$self->{tongue} = new Man::Tongue;
$self->{tongue}->speak();
$self->{tongue} = new Angel::Tongue;
$self->{tongue}->speak();
unless ( defined $self->{'love'} ) {
$self = {};
}
}
package Love;
sub patient { 1 }
sub kind { 1 }
sub envy { 0 }
sub boast { 0 }
sub proud { 0 }
sub rude { 0 }
sub seek_self { 0 }
sub keep_account {
my $self = shift;
for ( @_ ) {
$self->{account}{$_}++ unless /wrong/i;
}
}
sub delight {
my $self = shift;
local $_ = shift;
/wrong/i and return undef;
}
sub protect { 1 }
sub trust { 1 }
sub hope { 1 }
sub persevere { 1 }
--
John Porter
------------------------------
Date: Fri, 14 Aug 1998 01:21:55 -0400
From: rjk@coos.dartmouth.edu (Ronald J Kimball)
Subject: Re: X-file (?=...), case postponed.
Message-Id: <1ddq7ah.1aikknf1vsp1hcN@bay1-557.quincy.ziplink.net>
Patrick Timmins <ptimmins@netserv.unmc.edu> wrote:
> > The delimiters are put in the array between the elements they delimit,
> > of course.
>
> Where did it say that?
Where did you expect them to be put? At the end of the array?
> I don't insist, and I already get it.
Um... You're still insisting that regexes are mathematical expressions,
and you still don't get it.
> I'm just saying it could be
> unambiguous, but instead it isn't, because no where is it mentioned
> *when* the delimiters get throw into the array. And as far as the left
> to right bit, there is such a thing as back tracking, you know. :)
> Quick! Tell me what is in $1 before you evaluate what is in $2:
>
> $_ = "boink";
> /(.*)(oink)/;
$1 and family are only set when a match is successful. Thus, the phrase
"what is in $1 before you evaluate what is in $2" is meaningless.
To answer the question you meant to ask, before the regex engine
attempts to match the second parenthesized subexpression, the first
parethesized subexpression matches 'boink'. Then the regex engine
begins backtracking...
> or, doing inside out, just like a mathematical expression:
>
> $_ = "boink";
> /(boink(not!))/
At the point when the regex engine is about to attempt matching the
second parenthesized subexpression, the first parenthesized
subexpression has matched 'boink'. Then the match fails.
Once again, regexes are evaluated from *left to right*, not from the
inside out.
> The left to right numbering of $1, $2, etc, is to make it easy on us,
> but regexes backtrack, and do, indeed, enforce mathematical rules of
> precedence. That *is* relevant in my book.
No, it's not just to make it easy on us. That is the same as the order
in which the regex engine begins populating them.
My book is the Camel book, Programming Perl 2nd ed. What's yours?
> >
> > Otherwise I guess that /(ab(cd)ef)/ put 'cd' in $1 and 'abcdef' in $2...
>
> Again, the numbering argument is silly. I don't care what they're called,
> in your example you will never know what is in $1 until you evaluate what is
> in $2, just like a mathematical expression.
Once again, $1 and $2 are irrelevant unless the entire pattern matches
successfully.
When the regex is being matched, the potential contents of $2 are *not*
assigned before the potential contents of $1. When one parenthesized
subexpression is contained in another, the potential contents are
assigned *simultaneously* for any overlap.
In the above example, $1 potentially is 'a'. Then $1 potentially is
'ab'. Then $1 potentially is 'abc' and $2 potentially 'c'. Then $1
potentially is 'abcd' and $2 potentially is 'cd'. Then $1 potentially
is 'abcde' and $2 potentially is 'cd'. Then $1 potentially is 'abcdef'
and $2 potentially is 'cd'. Then the regex has matched, $1 is 'abcdef',
and $2 is 'cd'.
If matching proceeded inside out, then the regex engine would have to
try to match the 'cd' before it matched the 'abcdef'. That's just not
how it works.
> >
> > > Logically, I would expect Perl to do this with split, and the first
> > > element of the array should be the delimiter specified by '(.*)',
> > > which would be the whole EXPR, if '(.*)' were, logically, the first thing
> > > being evaluated.
> >
> > Suppose the string being split is 'a|b|c'. So, you want to put the
> > delimiter *before* the first element?? split(/(\|)/, 'a|b|c') would
> > return ('|', 'a', '|', 'b', 'c') or something like that. That's hardly
> > logical...
>
> No. That *is* illogical. Why would it throw out a parenthetical delimiter
> before it has reached one? That would be just as illogical as throwing out
> a 'J' before a 'Just another Perl Hacker\n' delimiter in:
>
> split/(?=(.*))/s, "Just another Perl Hacker\n";
Of course, that's not what Perl does, so it's okay that it would be
illogical. The actual delimiter is "ust another Perl Hacker\n",
*without the J*.
The delimiters appear *between the elements they delimit*. They do not
get shifted to before the elements. The null string matched by
/(?=(.*)/ delimits 'J' and 'u'. The subexpression matched by (.*) is
matched as *part of the delimiter*, so it appears in the resulting array
*between* 'J' and 'u'.
> since, as we have shown, the (.*) should properly be evaluated
> before the (?= ..)
No, we haven't shown that. You still don't get it.
The only effect of (?=) is to make the contained subexpression a
positive lookahead/zero-length assertion. It has nothing to do with
mathematical precedence.
> > Logically, the first element of the array should be the first element of
> > the delimited string. And that's how split works.
>
> Really, I could have sworn I read somewhere, and I quote:
>
> "If the PATTERN contains parentheses, additional array elements are
> created from each matching substring in the delimiter."
>
> You would think that if these delimiter substrings were encountered
> *before* any other characters in EXPR, that this would get thrown on
> to the array first in something like:
>
> split/(?=(.*))/s, "Just another Perl Hacker\n";
Yes, if delimiter substrings are encountered before other characters in
EXPR, they do get thrown into the array first. But in the above
statement, there are no delimiter substrings encountered before any
other characters in EXPR. When you split on a pattern that matches the
null string, split only splits *between* the characters in EXPR; it does
not split before the first character, or after the last.
> since, as we have shown, the (.*) should properly be evaluated
> before the (?= ..)
No, we haven't shown that. You still don't get it.
I cannot emphasize this enough:
Regexes are evaluated from left to right. They are not evaluated
inside-out.
> >
> > for (1..100) {
> > print "mathematical expressions != regular expressions\n";
> > }
> >
>
> true, but tack on to that:
>
> while (logical) {
> print "RE's obey mathematical parenthetical rules of precedence\n";
> }
You need one more thing to make that correct:
sub logical { 0 }
That also has the advantage of preventing an infinite loop.
In closing, regular expressions do not obey mathematical rules of
precedence. Regexes are not evaluated from the inside out.
Regexes are evaluated from left to right.
--
_ / ' _ / - aka - rjk@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: 12 Jul 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Mar 98)
Message-Id: <null>
Administrivia:
Special notice: in a few days, the new group comp.lang.perl.moderated
should be formed. I would rather not support two different groups, and I
know of no other plans to create a digested moderated group. This leaves
me with two options: 1) keep on with this group 2) change to the
moderated one.
If you have opinions on this, send them to
perl-users-request@ruby.oce.orst.edu.
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.misc (and this Digest), send your
article to perl-users@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.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 3445
**************************************