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

[Michael Brooks]

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

 

[Olivier Renaud]

Le samedi 24 mars 2007 15:40, Michael Brooks a =E9crit=A0:

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

The names of the methods puts and putc obviously come from the C language,=
=20
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 :
=AB Consistency does not come first in the Ruby's design. =BB

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

Regards,

=2D-=20
Olivier Renaud

 

[Jeremy McAnally]

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?

--Jeremy

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/

 

[_why]

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. Perhaps a
"schvits" is in order.

_why

 

[Peter Szinek]

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

 

[Devin Mullins]

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.

 

[Brian Candler]

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: ..."

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

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

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.

 

[Phillip Gawlowski]

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.

 

[David A. Black]

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

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

 

[Brian Candler]

At a minimum I think the "put_c", "put_s", etc... should be implemented

"My minimum demands are: ..."

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

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

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.

 

[David A. Black]

Hi --

(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." (I guess not


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)

 

[Martin DeMello]

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

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

 

[Brian Candler]

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." (I guess not

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

"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.

 

[Brian Candler]

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.

Hmm. Thinking about this a bit more: since this applies only to regexp
*literals*,

do_something if /foo/

would not be of any use if it were semantically equivalent to

do_something if true

So I started thinking along the lines of: instead of using global variable
$_ as a kind of temporary register to pass data between methods, how could
this construct be made more Rubyish? For example, like a case statement,
"if /foo/" could translate to "if /foo/ === self" ?

But then I realised: perhaps this is all just a marketing scam. Maybe $_ and
friends exist in the language, not because they have any real use, but just
to sucker in Perl programmers. They see them there, and think "great, this
is like Perl, I'll give Ruby a try". Once they're hooked, they won't use
them any more than the rest of us do.

If that's true, the construct clearly *has* to use $_ to fulfil its purpose


Regards,

Brian.

 

[David A. Black]

Hi --

Hmm. Thinking about this a bit more: since this applies only to regexp
*literals*,

do_something if /foo/

would not be of any use if it were semantically equivalent to

do_something if true

When I first saw this:

irb(main):001:0> puts "yes" if a = 1
(irb):1: warning: found = in conditional, should be ==

I found it annoyingly micromanaging -- until I saw that it only
happened with literals, and then I realized that it was being very
shrewd. It's interesting, then, that this non-construct can be used
to do the $_ thing. I wonder whether other cases, like if a = 1, are
going to pressed into service I hope not; I think the fact that
the regex one warns you and then goes ahead and does something other
than what it's warning you against suggests it could get pretty ugly.

So I started thinking along the lines of: instead of using global variable
$_ as a kind of temporary register to pass data between methods, how could
this construct be made more Rubyish? For example, like a case statement,
"if /foo/" could translate to "if /foo/ === self" ?

But then I realised: perhaps this is all just a marketing scam. Maybe $_ and
friends exist in the language, not because they have any real use, but just
to sucker in Perl programmers. They see them there, and think "great, this
is like Perl, I'll give Ruby a try". Once they're hooked, they won't use
them any more than the rest of us do.

If that's true, the construct clearly *has* to use $_ to fulfil its purpose

I'd love to see some of the Perl stuff disappear, and it's perenially
in the Ruby TODO file. I can hardly think of a case where I've seen
anyone use $_ in Ruby.


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)

 

[Brad Ediger]

I'd love to see some of the Perl stuff disappear, and it's perenially
in the Ruby TODO file. I can hardly think of a case where I've seen
anyone use $_ in Ruby.

I came to Ruby from Perl, and the $_ et al. definitely hooked me. But
I quickly drank the Kool-Aid and I haven't used the $_ in years.

--be

 

[David Morton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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


David Morton
Maia Mailguard http://www.maiamailguard.com
(e-mail address removed)



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGBvx8Uy30ODPkzl0RAjSSAKC1/YbgHml5r9qzhKqpnsuJXQAqqACfUcOv
W0BpRw0M+laAr9IT7cRFhGU=
=q0k0
-----END PGP SIGNATURE-----

 

[Josef 'Jupp' Schugt]

--------------enig67C7EB88EE1D7A9B7F502EEF
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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
--=20
Blog available at http://www.mynetcologne.de/~nc-schugtjo/blog/
PGP key with id 6CC6574F available at http://wwwkeys.de.pgp.net/


--------------enig67C7EB88EE1D7A9B7F502EEF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFGBwR0rhv7B2zGV08RAmq+AJ9crB2cx7UPRc6Xj+wI4ejEPkTeyACfTlZk
RxxU/OzQXdOQRFZFwXiOX8o=
=x+eo
-----END PGP SIGNATURE-----

--------------enig67C7EB88EE1D7A9B7F502EEF--

 

[Jeremy Henty]

?

I don't follow...

$ 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

 

[Brian Candler]

?

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

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