Suggestion: swap name of "puts" and "print" and rename "puts" to "put_s"

Hello:

I've been using Ruby on-and-off for about 4 weeks now and love it. However, some of the naming consistencies really bug me. The ones that bug me the most are the "print", "puts" and "putc".

I'd like to suggest that the functionality of the names "puts" and "print" should be swapped so that "print" automatically sends a newline character and "puts" doesn't. The reasons for this are as follows:

- "print" in other languages I've used (e.g. Basic) sends out a newline character.

- "putc" doesn't send out a newline so why should "puts".

- The "puts" method sounds like a techier name so it shouldn't be doing console style formatting and "print" sounds like the name you'd expect to be using with terminal / printer based formatted output.

Also, I'd like to suggest that the "putc", "puts", "gets" and "getc", etc... should be renamed to "put_c", "put_s", "get_s" and "get_c", etc... to keep their syntax consistent with the naming conventions used with "to_s", "to_a" and "to_i". Or alternately, rename "to_s", etc... to "tos", etc... Either way, just make it consistent.

At a minimum I think the "put_c", "put_s", etc... should be implemented and the "putc", "puts", etc... identified as obsolete syntax.

I realize these changes would effect every piece of Ruby code but the language is still fairly young (at least with respect to it's version number) and since it sounds like version 2.0 is going to break a few things it might be a good time to adjust a few names and conventions. I'm sure a little Ruby script using regular expressions could rename everything quite easily. Alternately, new versions of Ruby could have a command line switch to run the old syntax but by default would run the new syntax.

I apologize in advance for irritating anyone... I'm still new to Ruby and maybe I misunderstood some of the intentions behind the naming conventions. It's because Ruby is so consistent/smart in many other areas (I love the OO goodness) that this stuff (don't get me started on Find.find() or Benchmark.bm()) bugs me. I love promoting Ruby with co-workers but can't help but mention (or get asked) why some things like this look kind of silly.

Just a thought, have a good day everyone!

Michael

The names of the methods puts and putc obviously come from the C language,
where they act in the same way than in Ruby. This explains their behavior.

As for the consistency, I'd like to quote Matz on this :
« Consistency does not come first in the Ruby's design. »

I think that a majority of developper expects puts and putc to behave like it
does now, making Ruby easier to learn, even if the initial naming in C is
debatable.

Regards,

···

Le samedi 24 mars 2007 15:40, Michael Brooks a écrit :

Hello:

I've been using Ruby on-and-off for about 4 weeks now and love it.
However, some of the naming consistencies really bug me. The ones that
bug me the most are the "print", "puts" and "putc".

I'd like to suggest that the functionality of the names "puts" and
"print" should be swapped so that "print" automatically sends a newline
character and "puts" doesn't.
[...]
Michael

--
Olivier Renaud

The puts and putc methods are named after their C-equivalents, so I
see no real benefit in this change. Someone coming from C or C++
would be more comfortable with the current naming, whereas someone
like yourself (.e.g, coming from BASIC or Python or what have you)
would be more comfortable with your proposed naming. I think maybe
just keeping it the way it is will satisfy about the same amount of
people and keep all existing code in working order.

You have to learn a lot of new stuff when you learn Ruby, why not a
new output function? :wink:

--Jeremy

···

On 3/24/07, Michael Brooks <michael.brooks@shaw.ca> wrote:

Hello:

I've been using Ruby on-and-off for about 4 weeks now and love it.
However, some of the naming consistencies really bug me. The ones that
bug me the most are the "print", "puts" and "putc".

I'd like to suggest that the functionality of the names "puts" and
"print" should be swapped so that "print" automatically sends a newline
character and "puts" doesn't. The reasons for this are as follows:

- "print" in other languages I've used (e.g. Basic) sends out a newline
character.

- "putc" doesn't send out a newline so why should "puts".

- The "puts" method sounds like a techier name so it shouldn't be doing
  console style formatting and "print" sounds like the name you'd expect
to be using with terminal / printer based formatted output.

Also, I'd like to suggest that the "putc", "puts", "gets" and "getc",
etc... should be renamed to "put_c", "put_s", "get_s" and "get_c",
etc... to keep their syntax consistent with the naming conventions used
with "to_s", "to_a" and "to_i". Or alternately, rename "to_s", etc...
to "tos", etc... Either way, just make it consistent.

At a minimum I think the "put_c", "put_s", etc... should be implemented
and the "putc", "puts", etc... identified as obsolete syntax.

I realize these changes would effect every piece of Ruby code but the
language is still fairly young (at least with respect to it's version
number) and since it sounds like version 2.0 is going to break a few
things it might be a good time to adjust a few names and conventions.
I'm sure a little Ruby script using regular expressions could rename
everything quite easily. Alternately, new versions of Ruby could have a
command line switch to run the old syntax but by default would run the
new syntax.

I apologize in advance for irritating anyone... I'm still new to Ruby
and maybe I misunderstood some of the intentions behind the naming
conventions. It's because Ruby is so consistent/smart in many other
areas (I love the OO goodness) that this stuff (don't get me started on
Find.find() or Benchmark.bm()) bugs me. I love promoting Ruby with
co-workers but can't help but mention (or get asked) why some things
like this look kind of silly.

Just a thought, have a good day everyone!

Michael

--
http://www.jeremymcanally.com/

My free Ruby e-book:
http://www.humblelittlerubybook.com/book/

My blogs:
http://www.mrneighborly.com/
http://www.rubyinpractice.com/

well, the methods are already syntax consistent, where you can use put ==
print == printf, and puts is "put string" (I think, someone correct me).

And one of the things I like most about ruby is that there are more than one
way of using the same commands (e.g. the for loop sugar).

···

On 3/24/07, Michael Brooks <michael.brooks@shaw.ca> wrote:

Hello:

I've been using Ruby on-and-off for about 4 weeks now and love it.
However, some of the naming consistencies really bug me. The ones that
bug me the most are the "print", "puts" and "putc".

I'd like to suggest that the functionality of the names "puts" and
"print" should be swapped so that "print" automatically sends a newline
character and "puts" doesn't. The reasons for this are as follows:

- "print" in other languages I've used (e.g. Basic) sends out a newline
character.

- "putc" doesn't send out a newline so why should "puts".

- The "puts" method sounds like a techier name so it shouldn't be doing
  console style formatting and "print" sounds like the name you'd expect
to be using with terminal / printer based formatted output.

Also, I'd like to suggest that the "putc", "puts", "gets" and "getc",
etc... should be renamed to "put_c", "put_s", "get_s" and "get_c",
etc... to keep their syntax consistent with the naming conventions used
with "to_s", "to_a" and "to_i". Or alternately, rename "to_s", etc...
to "tos", etc... Either way, just make it consistent.

At a minimum I think the "put_c", "put_s", etc... should be implemented
and the "putc", "puts", etc... identified as obsolete syntax.

I realize these changes would effect every piece of Ruby code but the
language is still fairly young (at least with respect to it's version
number) and since it sounds like version 2.0 is going to break a few
things it might be a good time to adjust a few names and conventions.
I'm sure a little Ruby script using regular expressions could rename
everything quite easily. Alternately, new versions of Ruby could have a
command line switch to run the old syntax but by default would run the
new syntax.

I apologize in advance for irritating anyone... I'm still new to Ruby
and maybe I misunderstood some of the intentions behind the naming
conventions. It's because Ruby is so consistent/smart in many other
areas (I love the OO goodness) that this stuff (don't get me started on
Find.find() or Benchmark.bm()) bugs me. I love promoting Ruby with
co-workers but can't help but mention (or get asked) why some things
like this look kind of silly.

Just a thought, have a good day everyone!

Michael

These are very subtle things, but you make some good points. I
think "print" would be much friendlier if swapped with "puts." Especially
since puts is so filthy and derogatory to yiddish folk. Perhaps a
"schvits" is in order.

_why

···

On Sat, Mar 24, 2007 at 11:40:05PM +0900, Michael Brooks wrote:

I've been using Ruby on-and-off for about 4 weeks now and love it.
However, some of the naming consistencies really bug me. The ones that
bug me the most are the "print", "puts" and "putc".

Here ya go:

alias put_s puts
alias puts print

Cheers,
Peter

···

__
http://www.rubyrailways.com :: Ruby and Web2.0 blog
http://scrubyt.org :: Ruby web scraping framework
http://rubykitchensink.ca/ :: The indexed archive of all things Ruby

Michael Brooks wrote:

I'd like to suggest that the functionality of the names "puts" and "print" should be swapped so that "print" automatically sends a newline character and "puts" doesn't.

Hrm... That breaks the "Huffman-encoding" of the current scheme. #puts is by far the more used method, and so it's shorter. Maybe call it #put or #say, and then pick a longer name for the feedless version (maybe stick with #print, though something that acknowledged its correlation with #put would be nice).

   alias put puts
   alias put_on print # short for put_on_the_same_line
   alias eminence_front put_on # look it up
   undef puts; undef print
? **

Devin

* #p and #y are excused -- one-character names are illegibly short, so they can be reserved for little debug functions where terseness (tersion?) is of primary import.

** Not a serious proposition, you turd.

I've been using Ruby on-and-off for about 4 weeks now and love it.
However, some of the naming consistencies really bug me. The ones that
bug me the most are the "print", "puts" and "putc".

I'd like to suggest that the functionality of the names "puts" and
"print" should be swapped so that "print" automatically sends a newline
character and "puts" doesn't. The reasons for this are as follows:

- "print" in other languages I've used (e.g. Basic) sends out a newline
character.

That's languages *you've* used.

"print" in perl doesn't add a newline. Ruby borrows a lot from perl - in my
own opinion a little too much. But for people who need to switch frequently
between the two (including me), it's a small plus point that 'print' behaves
the same in both.

C doesn't have "print" but it has "printf", and that doesn't add a newline
either.

It's a long time since I wrote anything in BASIC.

- "putc" doesn't send out a newline so why should "puts".

Because that's how it is in the C language:

(From 'man puts')

       puts() writes the string s and a trailing newline to stdout.

Also, I'd like to suggest that the "putc", "puts", "gets" and "getc",
etc... should be renamed to "put_c", "put_s", "get_s" and "get_c",
etc... to keep their syntax consistent with the naming conventions used
with "to_s", "to_a" and "to_i". Or alternately, rename "to_s", etc...
to "tos", etc... Either way, just make it consistent.

At a minimum I think the "put_c", "put_s", etc... should be implemented
and the "putc", "puts", etc... identified as obsolete syntax.

"My minimum demands are: ..." :slight_smile:

One of the benefits I have found from using Ruby is that it actively
encourages you to chill out. Accept things as they are. Sure, it's not lean
and pure and orthogonal (if you want that, write in LISP, or Smalltalk).
Sure it doesn't do any static compile time checking - or even check that you
typed your variable names correctly. So write decent unit tests, which you
should be doing anyway, and kill two birds with one stone. Just relax and
code :slight_smile:

I realize these changes would effect every piece of Ruby code but the
language is still fairly young (at least with respect to it's version
number)

?!

I believe the language is coming up for 15 years old. And what have version
numbers to do with anything? If it was called Ruby 9.0 instead of Ruby 1.9,
would that affect your opinion?

and since it sounds like version 2.0 is going to break a few
things it might be a good time to adjust a few names and conventions.

Absolutely there may be an opportunity for things like this. But whilst
there is clarity in the unclouded eye of the newcomer, there's also validity
in the thoughts of those who have immersed themselves more in the language
and applied it to a variety of real world applications.

I'm sure a little Ruby script using regular expressions could rename
everything quite easily.

That statement demonstrates that you haven't gotten very far into Ruby at
all :slight_smile:

Firstly, the Ruby language is a complete pain to parse correctly. This is
one of its wrinkles. There's no formal grammar for it as far as I know, and
the C parser has lots of little rules and exceptions which means that things
like the position of a single white space can affect how a line is parsed.
This is all done so that the language "does the right thing" in as many ways
as possible, and generally works well. But it's hard to understand, and it's
hard to re-implement a parser from scratch which behaves the same as the
supplied one.

Secondly, the language is *totally* dynamic. If you see "puts foo" then this
could mean pretty much anything at runtime; classes can be loaded and
methods redefined a long time after the program starts *running*. Method
dispatch is dynamic, and you can call a method without even referring to it
by name. So you can't just parse the source code and make a
search-and-replace substitution and expect your program to be "fixed".

I love promoting Ruby with
co-workers but can't help but mention (or get asked) why some things
like this look kind of silly.

You'll get to build your own personal list of wrinkles, believe me. But
there's reasoning behind all of them, and I'll think you'll find all the
benefits outweigh the overhead of stamp-collecting.

Regards,

Brian.

···

On Sat, Mar 24, 2007 at 11:40:05PM +0900, Michael Brooks wrote:

Hi --

Hello:

I've been using Ruby on-and-off for about 4 weeks now and love it.
However, some of the naming consistencies really bug me. The ones that
bug me the most are the "print", "puts" and "putc".

I'd like to suggest that the functionality of the names "puts" and
"print" should be swapped so that "print" automatically sends a newline
character and "puts" doesn't. The reasons for this are as follows:

- "print" in other languages I've used (e.g. Basic) sends out a newline
character.

- "putc" doesn't send out a newline so why should "puts".

- The "puts" method sounds like a techier name so it shouldn't be doing
  console style formatting and "print" sounds like the name you'd expect
to be using with terminal / printer based formatted output.

Also, I'd like to suggest that the "putc", "puts", "gets" and "getc",
etc... should be renamed to "put_c", "put_s", "get_s" and "get_c",
etc... to keep their syntax consistent with the naming conventions used
with "to_s", "to_a" and "to_i". Or alternately, rename "to_s", etc...
to "tos", etc... Either way, just make it consistent.

At a minimum I think the "put_c", "put_s", etc... should be implemented
and the "putc", "puts", etc... identified as obsolete syntax.

I realize these changes would effect every piece of Ruby code but the
language is still fairly young (at least with respect to it's version
number) and since it sounds like version 2.0 is going to break a few
things it might be a good time to adjust a few names and conventions.
I'm sure a little Ruby script using regular expressions could rename
everything quite easily. Alternately, new versions of Ruby could have a
command line switch to run the old syntax but by default would run the
new syntax.

I apologize in advance for irritating anyone... I'm still new to Ruby
and maybe I misunderstood some of the intentions behind the naming
conventions. It's because Ruby is so consistent/smart in many other
areas (I love the OO goodness) that this stuff (don't get me started on
Find.find() or Benchmark.bm()) bugs me. I love promoting Ruby with
co-workers but can't help but mention (or get asked) why some things
like this look kind of silly.

This reminds me of the "old days" when so many people in the West
reacted to Ruby by saying, "I love this language, and by the way,
here's what should be changed to make it more attractive to
[Perl/Java/C[++]/...] programmers." My reaction was always: what
about Ruby programmers?

Very nostalgic :slight_smile: It always struck me as a strange mix of an
inferiority complex (Ruby exists to serve the needs of people who
mainly use other, somehow more "real" languages) and ambition (Ruby
should strive to be perfect [whatever that may mean]). The truth is
neither. Ruby is just Ruby. It's being worked on constantly, but
it's not a candidate language or an apprentice language or even a new
language.

If your co-workers are going to have a pea-under-the-mattress reaction
to seeing anything they don't think is perfect in Ruby, they're
holding Ruby to an unrealistically high standard -- in fact, not even
high; just unrealistic. It's like pushing a lump around under a
carpet: if puts and print get exchanged, then someone else will think
things are worse; and if they get changed back, you'll think it's
worse, and so on. The way out of the loop is to do what Ruby in fact
does: it's designed by Matz, who listens extremely carefully to a lot
of advice but ultimately makes the decisions himself.

In fact... you should check out the various venues for discussing
changes in the language (here, ruby-core, RCRchive). We do it all the
time. If you want to suggest something, you don't have to package it
in meta-rationalizations about what Ruby should be -- you can just
suggest it.

David

···

On 3/24/07, Michael Brooks <michael.brooks@shaw.ca> wrote:

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
   (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

I'd like to suggest that the functionality of the names "puts" and
"print" should be swapped so that "print" automatically sends a newline
character and "puts" doesn't.

Note that Ruby is written in C and that C's "puts" does return
carriage while its "printf" does not. Also note that POLS (principle
of least surprise) precisely taken is POLS2YM (principle of least
surprise to Yukikiro Matsumoto). Your suggestion seems to violate
this principle.

But now that you bring up the subject: What about adding a consistent
definition of write and write_ln? This would only change very little
and - which IMHO is important - does not unbearable introduce version
incompatibility. Changing the name of the basic output functions
would surely break literally every Ruby program. In other words: The
cost of changing them is much larger than the cost of living with
this kind of Altlast ("legacy" is one possible translation for this
word but it has quite a lot of other meanings as well, see
dict.leo.org or similar).

Josef 'Jupp' Schugt

···

--
Blog available at http://www.mynetcologne.de/~nc-schugtjo/blog/
PGP key with id 6CC6574F available at http://wwwkeys.de.pgp.net/

Brian Candler wrote:

C doesn't have "print" but it has "printf", and that doesn't add a newline
either.

Ruby has printf, though, which doesn't add a newline, too.

Looks like Ruby is making it easy for those Rubyists who are coming from another language, or are switching to and from another one, too.

···

--
Phillip "CynicalRyan" Gawlowski

Rules of Open-Source Programming:

22. Backward compatiblity is your worst enemy.

23. Backward compatiblity is your users' best friend.

> At a minimum I think the "put_c", "put_s", etc... should be implemented
> and the "putc", "puts", etc... identified as obsolete syntax.

"My minimum demands are: ..." :slight_smile:

One of the benefits I have found from using Ruby is that it actively
encourages you to chill out. Accept things as they are. Sure, it's not lean
and pure and orthogonal (if you want that, write in LISP, or Smalltalk).
Sure it doesn't do any static compile time checking - or even check that you
typed your variable names correctly. So write decent unit tests, which you
should be doing anyway, and kill two birds with one stone. Just relax and
code :slight_smile:

Addendum: I also think if you're going to discuss changes to the language,
it's more interesting if they are *significant* changes.

Methods names are, well, just names. The methods work the same whatever you
call them. You can argue that one is more obvious than the other, or easier
to guess or to remember, but that will very much depend on the background
you are coming from. For someone who is a non-English speaker, they will all
be equally opaque. Most of us should be grateful that Ruby doesn't use SJIS
squiggles for its method names :slight_smile:

I consider significant points to be *semantic*. These include:

(1) Semantic inconsistencies within the language. For example, there are
about 7 different ways to create a 'function' object (i.e. a block or proc),
and the semantics of calling them are subtly different, and indeed change
between versions of Ruby. I can recognise the different syntaxes, but I'd be
hard pressed to tell you from the top of my head how they differ
semantically.

(2) Semantic differences between ruby and apparently similar constructions
in other languages. Regexps provide an example; on the surface they look
very similar to perl, but underneath there are some important differences
you may not discover until it's too late.

For instance: in Perl, /^abc$/ matches only the string "abc". This is not
true in Ruby (although it *is* a valid regexp). To get the same behaviour in
Ruby, you need to write /\Aabc\z/

Regards,

Brian.

Isn't that putz?

Oy, gevault!

···

On 3/24/07, _why <why@ruby-lang.org> wrote:

On Sat, Mar 24, 2007 at 11:40:05PM +0900, Michael Brooks wrote:
> I've been using Ruby on-and-off for about 4 weeks now and love it.
> However, some of the naming consistencies really bug me. The ones that
> bug me the most are the "print", "puts" and "putc".

These are very subtle things, but you make some good points. I
think "print" would be much friendlier if swapped with "puts." Especially
since puts is so filthy and derogatory to yiddish folk.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

Hi --

···

On 3/24/07, Brian Candler <B.Candler@pobox.com> wrote:

(2) Semantic differences between ruby and apparently similar constructions
in other languages. Regexps provide an example; on the surface they look
very similar to perl, but underneath there are some important differences
you may not discover until it's too late.

For instance: in Perl, /^abc$/ matches only the string "abc". This is not
true in Ruby (although it *is* a valid regexp). To get the same behaviour in
Ruby, you need to write /\Aabc\z/

Ha -- talk about nostalgic -- when you wrote "Ruby borrows a lot from
perl - in my own opinion a little too much" in your previous post, my
first thought was, "I wonder if that means he's reconciled to the
anchors thing." :slight_smile: (I guess not :slight_smile:

David

--
Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
   (See what readers are saying! http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

Strongly disagree - method names are the user interface to your
language, and as such pretty important. Also, a bad decision gets
progressively harder to undo, so they're worth taking some time and
trouble over.

martin

···

On 3/25/07, Brian Candler <B.Candler@pobox.com> wrote:

Methods names are, well, just names. The methods work the same whatever you
call them. You can argue that one is more obvious than the other, or easier

?

I don't follow...

irb(main):006:0> a="abc"
=> "abc"
irb(main):007:0> a =~ /^abc$/
=> 0
irb(main):008:0> a="abcd"
=> "abcd"
irb(main):009:0> a =~ /^abc$/
=> nil
irb(main):010:0> a="aabc"
=> "aabc"
irb(main):011:0> a =~ /^abc$/
=> nil
irb(main):012:0> a = "something else with abc in it"
=> "something else with abc in it"
irb(main):013:0> a =~ /^abc$/
=> nil

David Morton
Maia Mailguard http://www.maiamailguard.com
mortonda@dgrmm.net

···

On Mar 24, 2007, at 4:30 PM, Brian Candler wrote:

For instance: in Perl, /^abc$/ matches only the string "abc". This is not
true in Ruby (although it *is* a valid regexp). To get the same behaviour in
Ruby, you need to write /\Aabc\z/

uhoh, I smell a new dialect of Ruby....
Ryiddish,
  or
Riddish?
  or
Rubish?

futz

···

On Mar 28, 2007, at 12:52 AM, Rick DeNatale wrote:

On 3/24/07, _why <why@ruby-lang.org> wrote:

On Sat, Mar 24, 2007 at 11:40:05PM +0900, Michael Brooks wrote:
> I've been using Ruby on-and-off for about 4 weeks now and love it.
> However, some of the naming consistencies really bug me. The ones that
> bug me the most are the "print", "puts" and "putc".

These are very subtle things, but you make some good points. I
think "print" would be much friendlier if swapped with "puts." Especially
since puts is so filthy and derogatory to yiddish folk.

Isn't that putz?

Oy, gevault!

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

:slight_smile:

Well, I think I am, more or less. It's just an example of the kind of
language difference which is more significant than just the name of a
method. It's still fresh in my mind though :slight_smile:

"Borrows a little too much from Perl": I was thinking of the global $_
variable, and Kernel#print / Kernel#gets which implicitly use it.

There's one time I use this construct, and that's when running Perl from the
command line to extract values from lines:

$ perl -ne 'print "$1\n" if /foo=(.*)/'

I still automatically use Perl for this. I had in my head that the
equivalent Ruby would be something like:

$ ruby -ne 'puts $1 if /foo=(.*)/ =~ $_'

Given that $_ is invoked explicitly there, you might as well write

$ ruby -ne 'puts $1 if /foo=(.*)/ =~ gets'

and not have the implicit $_ operation at all.

But checking this out, it looks like Ruby has special-cased this:

irb(main):006:0> $_ = "abcdef"
=> "abcdef"
irb(main):007:0> puts "xxx" if /abc/
(irb):7: warning: regex literal in condition
xxx
=> nil
irb(main):008:0> puts "xxx" if /ghi/
(irb):8: warning: regex literal in condition
=> nil

Ugh. So the rule which says "anything which is not 'nil' or 'false' is true"
is broken in this construct, and this is just to make ruby more perlish.

I also find it a bit of a pain that gets follows Perl by reading from all
files listed in ARGV. This means that when you really do want to read from
stdin, and your program uses ARGV for other things, then you have to write
"$stdin.gets"

Regards,

Brian.

···

On Sun, Mar 25, 2007 at 06:48:02AM +0900, David A. Black wrote:

On 3/24/07, Brian Candler <B.Candler@pobox.com> wrote:
>(2) Semantic differences between ruby and apparently similar constructions
>in other languages. Regexps provide an example; on the surface they look
>very similar to perl, but underneath there are some important differences
>you may not discover until it's too late.
>
>For instance: in Perl, /^abc$/ matches only the string "abc". This is not
>true in Ruby (although it *is* a valid regexp). To get the same behaviour
>in
>Ruby, you need to write /\Aabc\z/

Ha -- talk about nostalgic -- when you wrote "Ruby borrows a lot from
perl - in my own opinion a little too much" in your previous post, my
first thought was, "I wonder if that means he's reconciled to the
anchors thing." :slight_smile: (I guess not :slight_smile:

$ irb
irb(main):001:0> "\nabc\n" =~ /^abc$/
=> 1
irb(main):002:0> "\nabc\n" =~ /\Aabc\z/
=> nil
irb(main):003:0>

In Ruby ^, $ match the beginning and end of a line, whereas \A, \z
match the beginning and end of the whole string. This is not the same
thing for multiline strings.

In Perl, ^, $, \A, \z behave as Ruby's \A, \z, unless you specify the
m modifier to your regexp, in which case they all behave as they do in
Ruby.

From "perldoc perlre":

       m Treat string as multiple lines. That is, change "^" and "$"
   from matching the start or end of the string to matching the
   start or end of any line anywhere within the string.

Regards,

Jeremy Henty

···

On 2007-03-25, David Morton <mortonda@dgrmm.net> wrote:

On Mar 24, 2007, at 4:30 PM, Brian Candler wrote:

For instance: in Perl, /^abc$/ matches only the string "abc". This
is not
true in Ruby (although it *is* a valid regexp). To get the same
behaviour in
Ruby, you need to write /\Aabc\z/

?

I don't follow...

irb(main):001:0> a = "rm -rf /*\nabc\nreboot"
=> "rm -rf /*\nabc\nreboot"
irb(main):002:0> a =~ /^abc$/
=> 10

···

On Mon, Mar 26, 2007 at 07:49:38AM +0900, David Morton wrote:

>For instance: in Perl, /^abc$/ matches only the string "abc". This
>is not
>true in Ruby (although it *is* a valid regexp). To get the same
>behaviour in
>Ruby, you need to write /\Aabc\z/

?

I don't follow...

irb(main):006:0> a="abc"
=> "abc"
irb(main):007:0> a =~ /^abc$/
=> 0
irb(main):008:0> a="abcd"
=> "abcd"
irb(main):009:0> a =~ /^abc$/
=> nil
irb(main):010:0> a="aabc"
=> "aabc"
irb(main):011:0> a =~ /^abc$/
=> nil
irb(main):012:0> a = "something else with abc in it"
=> "something else with abc in it"
irb(main):013:0> a =~ /^abc$/
=> nil