Forum: Ruby regex

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Tom A. (Guest)
on 2006-01-16 15:33
(Received via mailing list)
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?
unknown (Guest)
on 2006-01-16 16:06
(Received via mailing list)
Hi --

On Mon, 16 Jan 2006, Tom A. wrote:

>
> "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
removed_email_address@domain.invalid

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
Tom A. (Guest)
on 2006-01-16 17:03
(Received via mailing list)
removed_email_address@domain.invalid 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.
unknown (Guest)
on 2006-01-16 17:12
(Received via mailing list)
Hi --

On Tue, 17 Jan 2006, Tom A. wrote:

> 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
removed_email_address@domain.invalid

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
David V. (Guest)
on 2006-01-17 02:58
(Received via mailing list)
On Mon, 16 Jan 2006 16:01:48 +0100, Tom A. 
<removed_email_address@domain.invalid>
wrote:

> 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 A. (Guest)
on 2006-01-17 02:58
(Received via mailing list)
>
> 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 V. (Guest)
on 2006-01-17 05:16
(Received via mailing list)
On Mon, 16 Jan 2006 22:29:45 +0100, Tom A. 
<removed_email_address@domain.invalid>
wrote:

> 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 V.
unknown (Guest)
on 2006-01-17 05:19
(Received via mailing list)
Hi --

On Tue, 17 Jan 2006, Tom A. wrote:

> 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
removed_email_address@domain.invalid

"Ruby for Rails", from Manning Publications, coming April 2006!
http://www.manning.com/books/black
This topic is locked and can not be replied to.