skip to content

In an IRB session, which built-in commands let you explore an unfamiliar object's methods, source code and documentation without leaving the console?

level: middleimportance: must knowfreq 52%

answer

  1. ls with -g to filter
  2. show_source, alias $, -s for super
  3. show_doc, alias ri, needs rdoc
  4. cd obj and cd ..
  5. edit opens VISUAL or EDITOR

basics

~20 s

IRB's ls lists an object's methods, constants and variables (-g filters them); show_source prints a Ruby method's definition; show_doc looks up its RDoc; cd moves self into an object; edit opens the file in your editor; help lists them all.

solid answer

~40 s

`help` lists every command and `help ls` explains one. `ls obj` groups an object's public methods by the class or module that defines them, plus constants, instance variables and class variables; `ls obj -g csv` filters with a regexp. `show_source CsvImporter#import` (alias `$`) prints the method's Ruby source with its file and line, `-s` walks to the `super` definition, and it cannot show methods written in C because they have no Ruby source location. `show_doc Array#each_slice` (alias `ri`) prints the installed RDoc. `cd importer` pushes the object as the new `self`, so its methods and ivars are reachable without a receiver; `cd ..` steps back out. `edit CsvImporter#import` opens that method's file in `$VISUAL` or `$EDITOR` but does not reload it.

code

ruby · 13 lines
ruby
irb(main):001> importer = CsvImporter.new
irb(main):002> ls importer -g import
CsvImporter#methods: import
irb(main):003> $ CsvImporter#import

From: csv_importer.rb:8

def import(text)
  ...
irb(main):004> cd importer
irb(#<CsvImporter:0x...>):005> @errors
=> []
irb(#<CsvImporter:0x...>):006> cd ..

go deeper

for a junior

Know that ls, show_source, show_doc and help exist and what each prints, and use them instead of guessing an object's API.

for a middle

Explain the limits: show_source needs a Ruby source_location, edit does not reload, and ls groups methods by the defining class or module.

for a senior

Show a fast path through unfamiliar code: ls to find the owner, show_source -s to follow super, cd into the object to read internal state, then a load after edit.

for a principal

Frame console exploration as part of onboarding and incident work: which console affordances you expect engineers to know, and when reading code beats probing a live object.

## Why IRB has commands at all At an IRB prompt most of what you type is Ruby, evaluated and echoed. On top of that, IRB recognises a set of **commands** — words it intercepts before Ruby sees them. Having picked up many of Pry's ideas, these commands cover most of what you need to explore code you did not write. `help` prints the full list grouped by category (Context, Workspace, Debugging, Misc…), and `help <command>` prints the usage of one. ## ls: what can this object do? `ls` with no argument describes the current `self` and the local variables in scope. `ls some_object` prints: - **public methods**, grouped by the class or module that defines them (singleton methods first, then the object's ancestors, stopping before `Object` for ordinary classes) — private helpers are not listed; - **constants**, when the object is a class or module; - **instance variables** and **class variables**. Because the grouping follows the ancestor chain, `ls` also answers "which mixin gave me this method?". Long lists are filtered with `-g` (or `-G`) and a regexp: `ls importer -g parse` shows only names matching `parse`. ## show_source and show_doc: where is it, what does it say? `show_source` (alias **`$`**) takes a constant, `Class#instance_method`, `receiver.method` or bare method name and prints the definition with its `From: file:line` header. Useful details: - `show_source CsvImporter#import -s` shows the **super** method, and `-ss` goes one level further up. - It relies on Ruby's `source_location`, which is `nil` for methods implemented in C, so `show_source String#upcase` reports that it could not locate a definition. Core classes written in C are the usual blind spot; that is when `show_doc` helps. - Methods defined earlier in the same IRB session are shown too. `show_doc` (alias **`ri`**) looks names up with RDoc's `ri` driver: `show_doc Array#each_slice`. With no argument it starts an interactive `ri` session. It needs the `rdoc` gem and installed documentation; in Ruby 4.0 rdoc is a bundled gem, and IRB prints a message instead of documentation when it cannot be loaded. ## cd and the workspace stack IRB keeps a **stack of workspaces**, each with its own `self`. The older commands `pushws`, `popws`, `cwws` and `workspaces` manage it; **`cd`** (since IRB 1.14) is the short form: | Command | Effect | |---|---| | `cd importer` | Evaluate `importer`, push it as the new `self`. The prompt label changes to the object. | | `cd ..` | Pop one workspace and return to the previous `self`. | | `cd` (no argument) | Pop every pushed workspace, back to the top level. | Inside an object you can read `@errors` directly and call private helpers without a receiver — handy for poking at a parser's internal state. ## edit, whereami and friends - **`edit`** opens a file in the editor named by `ENV["VISUAL"]` or `ENV["EDITOR"]`. `edit CsvImporter#import` finds the method's file first; with no argument it opens the file the current context came from. IRB does **not** reload the file afterwards: the running process keeps the old definition until you `load` it again. - **`whereami`** (alias **`@`**) reprints the code around the current `binding.irb`. - **`history -g pattern`** searches earlier input; **`copy`** puts the last value on the clipboard. ## A typical exploration 1. `ls importer` to see what the object offers and which module each method comes from. 2. `show_source importer.parse_line` to read the method you suspect. 3. `show_doc CSV::Row#to_h` for a library method whose source is not the point. 4. `cd importer`, then call private helpers and read ivars directly; `cd ..` when done. 5. `edit CsvImporter#parse_line` to fix it, then `load` the file to pick up the change.

  • Why does show_source String#upcase fail while show_source CsvImporter#import works?
    `show_source` uses the method's `source_location`, and Ruby returns `nil` for methods implemented in C, which covers most of `String`. There is no Ruby file to print, so IRB reports it could not locate a definition. `show_doc String#upcase` shows the documentation instead.
  • You fix a method with IRB's edit command and call it again at the prompt. Why is the old behaviour still there?
    `edit` only launches `$VISUAL` or `$EDITOR` on the file; it does not reload anything. The process still holds the old method definition until you `load` the file again (or restart the session), after which the reopened class picks up the new body.
  • How does ls show which module a method came from?
    `ls` walks the object's singleton class and then its ancestors, and prints a separate group per class or module that defines methods, labelled `SomeModule#methods`. A method listed under a mixin's group came from that module, which answers lookup questions without reading the ancestor chain by hand.

saying these in an interview costs you the question

  • show_source can print the C source of core methods like String#upcase.
  • edit reloads the changed file into the running IRB session automatically.
  • ls only lists methods and never shows instance variables or constants.
  • cd in IRB changes the process's working directory, like Dir.chdir.
  • show_doc works even when the rdoc gem cannot be loaded.