2012/3/1 Bartosz DziewoĹski [email protected]
ruby -e âp eval(â:-; 1â)â
The only bug here (or, IMO, a lack of feature) is that IRB does not
parse the code at all; it simply checks if the line ends with an
operator, a dot or a backslash, and in this case does not eval code
immediately, but joins it with next line of input.
â Matma R.
So, if Iâm reading you correctly, in your opinion, the real lacking
feature of IRB might be stated by demonstrating that, due to the fact
that IRB doesnât parse the code, the following fails:
$ irb
1.9.2p290 :001 > âHello worldâ
=> âHello worldâ
1.9.2p290 :002 > .gsub(/Hello/, âGoodbyeâ)
SyntaxError: (irb):2: syntax error, unexpected â.â
.gsub(/Hello/, âGoodbyeâ)
^
from /Users/kendall/.rvm/rubies/ruby-1.9.2-p290/bin/irb:16:in `â
1.9.2p290 :003 >
Whereas the follow works in ruby:
$ ruby <<EOF
âHello worldâ
.gsub(/Hello/, âGoodbyeâ)
EOF
(no output is printed, of course, but no error is raised either).
With, of course, IRB trying to be a little helpful with some
simplistic line-parsing rules in place (as opposed to full language
parsing) which is the cause of some of the âweirdâ behavior thatâs
been pointed out (and it is âweirdâ to have a language environment
provided REPL tool appear to silently ignore lines of code since it
doesnât print out the âignoredâ statementâs value)
That said, itâs good to understand now that it may be necessary, for
specific code statements in IRB, to explicitly terminate some lines of
code:
$ irb
1.9.2p290 :001 > :- ;
1.9.2p290 :002 >
1.9.2p290 :003 >
Oops! IRB just ignored my explicit semi-colon???