Bash edits the command line through the GNU Readline library. What does pressing Ctrl-R at a bash prompt do, and where do you make a change to bash's keybindings or editing mode permanent?
answer
- incremental search, not a menu
- the library, not bash, owns the keys
- one config file for many programs
- emacs mode is the default
- re-read the file without a new shell
basics
~20 sCtrl-R starts an incremental reverse search through the current session's command history: keep typing to narrow it, press Ctrl-R again for older matches, Enter to run. Persist keybinding and editing-mode changes in ~/.inputrc, or with bind in ~/.bashrc.
solid answer
~40 s`Ctrl-R` opens readline's incremental reverse search — the prompt changes to `(reverse-i-search)` and each character you type narrows the match against the in-memory history. Pressing `Ctrl-R` again steps to the next older match, Enter runs the match, and `Ctrl-G` aborts and restores the line you had. Readline also supplies the everyday editing keys: `Ctrl-A`/`Ctrl-E` for start and end of line, `Ctrl-W` to kill the previous word, `Ctrl-U` to kill to the start, `Ctrl-Y` to yank it back — the defaults of readline's **emacs** editing mode. To make a change permanent, put it in `~/.inputrc`, readline's own config file shared by every readline-using program, with lines like `set editing-mode vi`, `set completion-ignore-case on`, or a binding such as `"\e[A": history-search-backward`. Bash-only alternatives are `set -o vi` and the `bind` builtin in `~/.bashrc`.
code
bash · 6 lines# ~/.inputrc
$include /etc/inputrc
set completion-ignore-case on
set show-all-if-ambiguous on
"\e[A": history-search-backward
"\e[B": history-search-forwardgo deeper
Be able to demonstrate Ctrl-R live and name a few editing keys such as Ctrl-A, Ctrl-E and Ctrl-W. Say that ~/.inputrc is where readline settings live.
Explain that readline is a shared library rather than a bash feature, and describe both configuration routes: set and binding lines in ~/.inputrc, and the bash bind builtin including bind -x for running a shell function from a key.
Show judgment about shared environments: which readline settings you standardise for a team, why arrow keys break in minimal container shells, and how prefix-based history search beats teaching people to scroll.
Treat prompt ergonomics as an engineering cost worth measuring. Weigh a small documented shared inputrc against per-person setups, and keep interactive conveniences from becoming hidden dependencies of scripts or automation.
## What readline is Readline is a separate GNU library that bash links against to provide the editable command line: cursor movement, killing and yanking, history recall, and completion. It is not bash-specific — `gdb`, `psql` and many other tools use it too, which is why one `~/.inputrc` changes all of them at once. ## The search keys `Ctrl-R` invokes `reverse-search-history`. The prompt is replaced by `(reverse-i-search)` and the search is *incremental*: each keystroke re-searches the in-memory history list for the most recent line containing what you have typed so far. - `Ctrl-R` again — jump to the next older match. - Enter — execute the shown line. - Right arrow, `Ctrl-A`, or any cursor-movement key — accept it into the editing buffer without running it, so you can modify it first. This is the safe habit: never blind-Enter on a half-recognised destructive command. - `Ctrl-G` — abort and restore whatever you were typing before the search. `Ctrl-S` is the forward counterpart (`forward-search-history`), but in most terminals `Ctrl-S` is swallowed by the terminal driver's XON/XOFF flow control and appears to freeze the terminal (`Ctrl-Q` unfreezes it). `stty -ixon` in `~/.bashrc` frees the key. ## The default editing keys Readline starts in emacs mode. The set worth internalising is small: ``` Ctrl-A / Ctrl-E beginning / end of line Alt-B / Alt-F back / forward one word Ctrl-W kill the word before the cursor Ctrl-U kill from cursor to start of line Ctrl-K kill from cursor to end of line Ctrl-Y yank back the last killed text Ctrl-L clear the screen, keeping the current line Alt-. insert the last argument of the previous command ``` `Alt-.` in particular saves an enormous amount of retyping. ## Making changes permanent **`~/.inputrc`** is readline's configuration file (overridable with the `INPUTRC` environment variable; the system-wide file is usually `/etc/inputrc`). It holds two kinds of lines — `set VARIABLE value` for readline variables, and `"key sequence": function-or-macro` for bindings: ``` $include /etc/inputrc set editing-mode vi set completion-ignore-case on set show-all-if-ambiguous on "\e[A": history-search-backward "\e[B": history-search-forward ``` That last pair is the popular one: type a prefix, then press Up, and you cycle only through history entries starting with that prefix. **`bind` in `~/.bashrc`** does the same thing from bash. `bind '"\e[A": history-search-backward'` is equivalent to the inputrc line, `bind -f ~/.inputrc` re-reads the file, and `bind -x '"\C-o": some_shell_function'` binds a key directly to a shell command — something plain inputrc syntax cannot do. To discover names and current bindings, `bind -p` lists every binding with its function name and `bind -P` prints them in a readable form. **Editing mode.** `set -o vi` (bash) or `set editing-mode vi` (inputrc) switches to vi-style editing: you start in insert mode, `Esc` moves to command mode, normal vi motions apply, and `/` searches history. `set -o emacs` returns to the default. Adding `set show-mode-in-prompt on` to `~/.inputrc` makes the current vi mode visible, which removes most of the beginner pain. ## Two things worth knowing - Changes to `~/.inputrc` do not affect already-running shells until they re-read it — `Ctrl-X Ctrl-R` is bound to `re-read-init-file`, and `bind -f ~/.inputrc` does the same from the prompt. - If your keys emit odd characters instead of moving the cursor, the shell may not be using readline at all: `sh`, `dash` and `bash --noediting` give you a dumb line with no editing, which is why arrow keys print `^[[A` in a minimal container shell. ## Why this is worth configuring Every second spent retyping a long command is friction repeated hundreds of times a day. Prefix history search, case-insensitive completion and `Alt-.` are three small settings that remove most of it — and because they live in readline rather than in bash, they follow you into every other readline-based tool on the machine.
- Why does Ctrl-S sometimes appear to freeze the terminal instead of searching forward?The terminal driver interprets Ctrl-S as XON/XOFF flow control and stops output before readline ever sees the key; Ctrl-Q resumes it. Disabling that with `stty -ixon` in `~/.bashrc` hands the key back to readline's `forward-search-history`.
- You add a binding to ~/.inputrc but your open shell ignores it. What now?Readline reads its init file at startup, so a running shell keeps the old bindings. Press `Ctrl-X Ctrl-R`, which is bound to `re-read-init-file`, or run `bind -f ~/.inputrc` from bash. A newly started shell picks it up automatically.
- What is the difference between putting `set editing-mode vi` in ~/.inputrc and `set -o vi` in ~/.bashrc?They select the same readline mode at different scopes. The inputrc line applies to every program that links readline — `gdb`, `psql` and others — while `set -o vi` is a bash option affecting only bash sessions that read that rc file. Use inputrc when you want consistency across tools.
saying these in an interview costs you the question
- Thinks Ctrl-R searches the history file rather than the in-memory list
- Says keybindings can only be configured in ~/.bashrc
- Confuses readline's vi mode with launching the vi editor
- Believes ~/.inputrc changes apply instantly to running shells
- Claims arrow-key editing works in every shell, including dash