Problem with 'chomp'

Simple program:

while($_ != “q”)
puts “Running…”
print "Enter q to quit: "
gets
chomp
end

However - getting the following in any progams in which I use ‘chomp’:
'undefined local variable or method ‘chomp’ for main: Object (NameError)

On Tue, Sep 7, 2010 at 12:11 AM, Barry O’gorman
[email protected] wrote:

Simple program:

while($_ != “q”)
  puts “Running…”
  print "Enter q to quit: "
  gets
  chomp
end

However - getting the following in any progams in which I use ‘chomp’:
'undefined local variable or method ‘chomp’ for main: Object (NameError)

chomp, gsub, and others can only be used without a receiver in
one-liners. They are thought for making -p loops and such short.

In regular Ruby you normally use explicit variables (and in regular
Perl you normally also do).

On Mon, Sep 6, 2010 at 3:11 PM, Barry O’gorman [email protected]
wrote:

Simple program:

while($_ != “q”)
  puts “Running…”
  print "Enter q to quit: "
  gets
  chomp
end

However - getting the following in any progams in which I use ‘chomp’:
'undefined local variable or method ‘chomp’ for main: Object (NameError)

At least in Ruby 1.9, Kernel#chomp only exists when the -n or -p
command-line options are used when launching ruby, and mostly would
only be used when you are putting the code all on the ruby command
line. If you want to take lines from the programs input, chomp them,
and send them (now run together) to the output until you hit a “q” by
itself in the input, this should do the trick:

ruby -p -e “chomp; $_ == ‘q’ ? break : $_”

Really? I’m using ruby 1.8.7 (on a mac) and the code runs fine for me.
Not
that I disagree with the comment though: I think the receiver should be
used
for clarity.

btw, runs fine in irb and ruby proper.

On Tue, Sep 7, 2010 at 12:59 AM, Sven S. [email protected]
wrote:

Really? I’m using ruby 1.8.7 (on a mac) and the code runs fine for me. Not
that I disagree with the comment though: I think the receiver should be used
for clarity.

Yeah, it’s new in 1.9.

On Mon, Sep 6, 2010 at 10:20 PM, Sven S. [email protected]
wrote:

Really? I’m using ruby 1.8.7 (on a mac) and the code runs fine for me.
Not
that I disagree with the comment though: I think the receiver should be
used
for clarity.

Yeah, it’s new in 1.9.

I use 1.8.7 on my Macbook Pro, running Snow Leopard, because all other
versions are painfully slow (maybe an rvm problem?)
I use 1.9.1 on my Hackintosh desktop, running Leopard, it is not slow
there,
so I use it.

But I always reference the 1.8.6 docs anyway, so hypothetically anything
I
write should be good for either of them, unless a gem has issues.

All my friends are on 1.9.1, Heroku is on 1.8.7, at my work it was a mix
between 1.8.6 and 1.8.7

On 07.09.2010 05:20, Sven S. wrote:

Slightly offtopic, but is everyone using 1.9? Are my marbles rolling away
because I’m still on 1.8?

Yes. And you will die.

Seriously: I think we are still in a transitional phase. It does seem
though that most people coming to the language now start out 1.9ish.
Applications which are around for a while are likely to still use 1.8
(or even 1.8.6).

Only on 1.8 because I thought that was still the official stable version.
(i.e. won’t break anything)

Currently I’d say if robustness is your main concern that is probably
the best choice. And I guess that will be true for a while (maybe a
year or so) although my crystal ball rolled away yesterday so please
take it with a grain of salt. :slight_smile:

Kind regards

robert

Sven S. wrote:

Slightly offtopic, but is everyone using 1.9?

I’m almost certainly in a minority, but I won’t touch 1.9 because of the
String madness[1][2]. ruby <= 1.8.x is a wonderful language.

Regards,

Brian.

[1] http://github.com/candlerb/string19/blob/master/string19.rb
[2] http://github.com/candlerb/string19/blob/master/soapbox.rb

Slightly offtopic, but is everyone using 1.9? Are my marbles rolling
away
because I’m still on 1.8?

Only on 1.8 because I thought that was still the official stable
version.
(i.e. won’t break anything)

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs