regex

[Tom Allison]

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?

 

[Robert Klemme]

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/language.html#UJ

robert

 

[dblack]

Hi --

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')

???

/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).

What about the 'x' option?

What about it? It's there if you want to use it.


David

--
David A. Black
(e-mail address removed)

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black

 

[Tom Allison]

/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]

Hi --

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.

It's like so many things: if languages just did what older languages
did, there would be no point in having new languages


David

--
David A. Black
(e-mail address removed)

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black

 

[David Vallner]

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. =20
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 =20
whole family.

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

 

[Tom Allison]

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]

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

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

David Vallner

 

[dblack]

Hi --

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.

Then you'll have to blame Perl, for breaking away from sed
There's really never been one regex syntax, across all these various
languages and utilities; it's a very, very unlikely area for
uniformity. In any case, Perl didn't necessarily get everything right
-- for example, it's nice to have anchors for all possible
combinations of start/end and string/line, as Ruby does. (Maybe
recent Perls do too; I'm not sure.)


David

--
David A. Black
(e-mail address removed)

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black