Some local variables are defined by default

JunichiIto commented 3 years ago

Description

Some local variables are defined by default.

irb(main):001:0> local_variables
=> [:_, :version, :str]

The result is different from the command below:

$ ruby -e "p local_variables"
[]

I think IRB should have no local variables by default.

Result of irb_info

irb(main):001:0> irb_info
=>
Ruby version: 3.0.1
IRB version: irb 1.3.6 (2021-06-19)
InputMethod: ReidlineInputMethod with Reline 0.2.6
RUBY_PLATFORM: arm64-darwin20

Terminal Emulator

Terminal app in macOS.

Setting Files

Are you using ~/.irbrc and ~/.inputrc? => No.

pocke commented 3 years ago

https://github.com/rubygems/rubygems/blob/de0c8fb2b1f514135b5f35e6d6a259264f909edc/lib/rubygems/installer.rb#L765-L767 Just FYI, probably str and versions variables are defined by RubyGems.

pocke commented 3 years ago

https://github.com/ruby/irb/pull/206 This pull request will fix this issue.

aycabta commented 3 years ago

@JunichiIto I think it's good to receive many reports, but they all say that "the problem is that the IRB itself and the code entered into the IRB are executed in the same interpreter".

I understand that there are minor differences between them, but try writing a patch first. It's difficult to respond if you file many similar reports for essentially the same issue without understanding what is in them.

JunichiIto commented 3 years ago

@aycabta Thank you for your reply. My response is very long and difficult to explain in English, so I wrote the reply here in Japanese.

The below is auto-translated version with Google translation (I manually corrected some sentences.)

First of all, let me thank you. Thank you for developing irb every day as an open source activity. The new irb has become very convenient. I have high expectations for future evolution.

After clarifying this point, I will write a reply.

I think it's good to receive many reports, but they all say that "the problem is that the IRB itself and the code entered into the IRB are executed in the same interpreter".

I agree with you. I also understand that for implementation reasons, the behavior when executed with the IRB and ruby commands can be slightly different.

So let me explain why I have posted such issues so many times.

I publish an introductory book on Ruby called "Introduction to Ruby Programming for Future Professionals". In it, the explanation "Let's execute the sample code on irb" is included.

The sample code in the book is explained on the assumption that it works basically the same on the IRB and ruby command. In fact, at the time of writing the first edition of this book, in the days of Ruby 2.4, IRBs behaved much like they did when run with the ruby command.

And now I'm writing a revised version of this book. The revised version targets Ruby 3.0.1. Naturally, I also use the IRB that is installed with Ruby 3.0.1. Since it is a revision of an existing book, many sample codes are the same as the first edition. However, when I ran it in IRB, I found some results are different from the ones in ruby command. This behavior is also different from Ruby 2.4.

"Introduction to Ruby Programming for Future Professionals" is aimed at beginners who are not yet familiar with the Ruby language. It would be easy for me to think "it is natural that the results of the IRB and ruby commands are different", but it is difficult for newbies. In fact, the issue reported at https://github.com/ruby/irb/issues/256 is from a reader who ran the sample code of the first edition on the IRB of Ruby 3.0. He was confused by the different behavior between IRB and the explanation in the book.

Of course, if they save the sample code to a file and execute it with the ruby command, they will get the same result as the explanation in the book, but it will be more time-consuming than executing it on the IRB. I would like to recommend IRB as the best learning environment in Ruby even in the revised version.

I think your point that "try writing a patch first" is also true. However, my skills do not allow me to write patches right away. Therefore, I registered the issue with the idea that "first of all, just a report". However, I will refrain from doing so in the future.

Also, regarding the difference between the execution result of IRB and ruby command, I will add a comment such as "Since the execution result is different on IRB, save the sample code to a file and execute it with ruby command" in the book as appropriate.

st0012 commented 10 months ago

@JunichiIto With the current latest release (1.8.3), the default local variables is now down to just _, which I think it's already a significant improvement.

irb(main):001> local_variables
=> [:_]
irb(main):002>

I also want to emphasize that while I understand the concern of confusion, IRB session will never be a perfectly clean Ruby environment. And since _ is required to retrieve the previous returned value, which is an important feature, I don't plan to remove it atm. So I'm closing this now.

If you find _'s definition causing other issues than confusion to new Rubyists, feel free to open another issue.

ruby / irb