Ruby Interactive Shell: Clear All Variables That Have Been Set In IRB Session

The Interactive Ruby Shell, or IRB, doesn’t have a way to clear all variables that I am aware of besides quitting irb and then restarting irb however you can simulate this by invoking subirbs. Subirbs are jobs underneath the main irb session that will allow you to work within irb on different code at the same time without having to stop irb and restart it. So you can load certain gems from the main irb session and not be required to reload them for each subirb. Below are some examples of how subirbs or irb jobs are used.

Clear All IRB Variables By Using SubIRBs or IRB Jobs:

Launch IRB: First launch irb from the command line on your server.
bash
1. [web@idev atp]$ irb
2. irb(main):001:0>
Load Ruby Gems: Now enable the necessary Ruby Gems from the main IRB session. In this example we will load the fastercsv gem to parse a CSV file and show how the gem is still available in a subirb job.
ruby
1. irb(main):001:0> require 'rubygems'
2. => true
3. irb(main):002:0> require 'fastercsv'
4. => true
5. irb(main):003:0>
Create Array From Parsing CSV File: Now we are going to create an array in the main irb session by parsing through a CSV file. Once the array is created we will print out the second field in the first row to verify data is in the array.
ruby
1. irb(main):014:0> devices=[]
2. => []
3. irb(main):015:0> FCSV.foreach("devices.csv", :quote_char => '"', :col_sep =>'|', :row_sep =>"\n") do |row|
4. irb(main):016:1* b = row
5. irb(main):017:1> devices << b irb(main):018:1> end
6. => nil
7. irb(main):019:0>
8. irb(main):020:0> puts devices[0][1]
9. H210000027
10. => nil
As you can see above the devices array was created and then to verify the data we printed the second field of the first row which happens to be the serial number field in the devices.csv file.
Create SubIRB Or IRB Job: Now we will create a subirb by simply typing irb from the irb prompt as shown below. At any time while using irb you can view all of the active subirbs by typing jobs which is also shown below.
ruby
1. irb(main):021:0>
2. irb(main):022:0*
3. irb(main):023:0* irb
4. irb#1(main):001:0>
5. irb#1(main):002:0* jobs
6. => #0->irb on main (#
7. : stop)
8. #1->irb#1 on main (#
9. : running)
10. irb#1(main):003:0>
Notice at this point we have the main irb session which shows as “stopped” and the subirb.
Call Array, Create New Array: Now in the subirb attempt to call the array created in the primary irb session by issuing the same command in step 3 (puts devices[0][1]) as shown below. This will return an error because that array does not exist in the subirb. The cool thing I did want to show though is the fact that the fastercsv gem is still loaded as proved by the new devices array created below using the new-devices.csv file.
ruby
1. irb#1(main):003:0> puts devices[0][1]
2. NameError: undefined local variable or method `devices' for main:Object
3. from (irb#1):3
4. irb#1(main):012:0>
5. irb#1(main):013:0*
6. irb#1(main):014:0*
7. irb#1(main):015:0*
8. irb#1(main):016:0* devices=[]
9. => []
10. irb#1(main):017:0> FCSV.foreach("new-devices.csv", :quote_char => '"', :col_sep =>'|', :row_sep =>"\n") do |row|
11. irb#1(main):018:1* c = row
12. irb#1(main):019:1> devices << c irb#1(main):020:1> end
13. => nil
14. irb#1(main):021:0> puts devices[0][1]
15. H1D0000001
16. => nil
17. irb#1(main):022:0>
Now in the subirb we have created another array also called devices that reads a different CSV file so when we call the second field of the first row it is different than the previous devices array.
Change Job, Verify Array: Now that we have shown that the Ruby Gems will be available in all subirbs we can switch back to the primary irb session and verify that the devices array that was initially created is the same as it initially was. In the below example after switching back to the primary irb session and verifying the original devices array we again switch back to the subirb and show that the second devices array is also not changed.
ruby
1. irb#1(main):022:0>
2. irb#1(main):023:0* fg 0
3. => #, @signal_status=:IN_EVAL, @scanner=#>
4. irb(main):024:0> puts devices[0][1]
5. H210000027
6. => nil
7. irb(main):025:0> fg 1
8. => #, @signal_status=:IN_EVAL, @scanner=#>
9. irb#1(main):024:0> puts devices[0][1]
10. H1D0000001
11. => nil
12. irb#1(main):025:0>
Clear SubIRBs: Last but not least we show below how to remove subirbs. This is what can simulate removing all variables from an irb session without having to restart irb. After killing the subirb job you can create another subirb which will have the first job id available as shown below. We also show that in the new job the devices array is no longer available because the subirb where it existed was removed and then recreated similar to resetting all of the variables in an irb session.
ruby
1. irb(main):026:0> jobs
2. => #0->irb on main (#
3. : running)
4. #1->irb#1 on main (#
5. : stop)
6. irb(main):027:0> kill 1
7. => [1]
8. irb(main):028:0> irb
9. irb#1(main):001:0> jobs
10. => #0->irb on main (#
11. : stop)
12. #1->irb#1 on main (#
13. : running)
14. irb#1(main):002:0> puts devices[0][1]
15. NameError: undefined local variable or method `devices' for main:Object
16. from (irb#1):2
17. irb#1(main):003:0>

So while the above doesn’t allow you to clear all variables in the primary IRB session you can see how by using subirbs you can get the same effect. If you don’t set any variables in the primary IRB session then you could reset each subirb or irb job without ever leaving IRB itself. This is nice because then you only have to load the Ruby Gems you require once instead of having to stop irb, start irb, and then load the Ruby Gems again.