[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

regex

Tom Allison

1/16/2006 1:30:00 PM

I'm digging through the Pragmatic Programmers book and had some
questions about regex support.

Initially they only mention .sub and .gsub.

If I wanted to write a regex block using additional flags, say something
like this:
s/perl/ruby/igsm

What that be expressed as:

"my favorite programming language is perl".gsub(/perl/ism, 'ruby')

???
What about the 'x' option?
8 Answers

Robert Klemme

1/16/2006 2:00:00 PM

0

Tom Allison wrote:
> I'm digging through the Pragmatic Programmers book and had some
> questions about regex support.
>
> Initially they only mention .sub and .gsub.
>
> If I wanted to write a regex block using additional flags, say
> something like this:
> s/perl/ruby/igsm
>
> What that be expressed as:
>
> "my favorite programming language is perl".gsub(/perl/ism, 'ruby')

Yes. Depending on circumstances you might as well use gsub! which
modifies the string in place.

> ???
> What about the 'x' option?

http://www.ruby-doc.org/docs/ProgrammingRuby/html/langua...

robert

dblack

1/16/2006 2:06:00 PM

0

Tom Allison

1/16/2006 3:02:00 PM

0

dblack@wobblini.net wrote:
>
> /s turns on SJIS encoding, so you probably don't want that. As for
> all the multiline matching, etc., /m causes the wildcard dot to match
> newline characters, like /s in Perl. You don't need an equivalent of
> Perl's /m because ^ and $ already always match beginning/end of lines.
> To match beginning/end of string, you use anchors: \A and \z (or \Z to
> discount a final newline).

There's a lot of differences to get used to here.
I'm surprised that Ruby would go contrary to Perl in the regex flags.
It's bound to be a source of confusion, at least for myself.

dblack

1/16/2006 3:11:00 PM

0

David Vallner

1/16/2006 8:10:00 PM

0

On Mon, 16 Jan 2006 16:01:48 +0100, Tom Allison <tallison@tacocat.net>
wrote:

> dblack@wobblini.net wrote:
>> /s turns on SJIS encoding, so you probably don't want that. As for
>> all the multiline matching, etc., /m causes the wildcard dot to match
>> newline characters, like /s in Perl. You don't need an equivalent of
>> Perl's /m because ^ and $ already always match beginning/end of lines.
>> To match beginning/end of string, you use anchors: \A and \z (or \Z to
>> discount a final newline).
>
> There's a lot of differences to get used to here.
> I'm surprised that Ruby would go contrary to Perl in the regex flags.
> It's bound to be a source of confusion, at least for myself.
>


AND here's a completely new regexp engine coming for 2.0 - fun for the
whole family.

That said, although it's undesirable, noone's obliged to be completely
PCRE-compatible, and it always pays to take five minutes to read the (IMO
pretty clear as far as regexps are concerned) documentation.

Tom Allison

1/16/2006 9:30:00 PM

0


>
> AND here's a completely new regexp engine coming for 2.0 - fun for the
> whole family.
>
> That said, although it's undesirable, noone's obliged to be completely
> PCRE-compatible, and it always pays to take five minutes to read the
> (IMO pretty clear as far as regexps are concerned) documentation.
>

Considering that PCRE is pretty much a language in itself, it would make
life a hell of a lot easier if there was at least some effort to either
stick to the established norms of regex engines or at least avoid
treading on them in the name of being different. regexp isn't trivial,
making it more varied from language to language isn't going to help
matters much.

David Vallner

1/17/2006 2:38:00 AM

0

On Mon, 16 Jan 2006 22:29:45 +0100, Tom Allison <tallison@tacocat.net>
wrote:

>
>> AND here's a completely new regexp engine coming for 2.0 - fun for
>> the whole family.
>> That said, although it's undesirable, noone's obliged to be
>> completely PCRE-compatible, and it always pays to take five minutes to
>> read the (IMO pretty clear as far as regexps are concerned)
>> documentation.
>>
>
> Considering that PCRE is pretty much a language in itself, it would make
> life a hell of a lot easier if there was at least some effort to either
> stick to the established norms of regex engines or at least avoid
> treading on them in the name of being different. regexp isn't trivial,
> making it more varied from language to language isn't going to help
> matters much.
>


Well, I think Oniguruma, the new regexp engine, is a bit closer to PCRE in
feature availability. And the changes to regexp options don't seem that
catastrophical to me, I'd rather express my intention in the pattern
itself than changing its behaviour globally or using option grouping
inside it.

David Vallner

dblack

1/17/2006 2:42:00 AM

0