Text Processing for Network Engineers Part 7: nano and Picking the Right Editor for the Job

Part 6 made the case for vim: it’s always there, and its power features are worth the up-front cost. This part is shorter, because the case for nano is simpler: sometimes the up-front cost isn’t worth paying, and that’s a legitimate engineering judgment, not a lesser one.

When nano is the right call

• A quick, one-line edit on a box you don’t manage day to day. You don’t need vim’s macros or visual block mode to change one IP address in a config file you’ll never open again. Modal editing has a real cost the first few times: hitting i to type, forgetting to hit Esc before :wq, and watching the terminal fill with 1s because you typed a count into normal mode by accident. nano has none of that risk, because there’s no mode to be in the wrong one of.
• Handing a task to someone less experienced, live, over a shared screen. “Open the file, arrow to the line, change the number, Ctrl-O to save, Ctrl-X to exit” is a complete instruction set nano prints on screen, permanently, at the bottom of every session. vim’s equivalent instruction requires the other person to already know vim.
• Under real time pressure, mid-incident. This is the honest reason nano earns a place in this series at all. At 3am, with a maintenance window closing, the mode-based cognitive overhead of vim is a real cost, however small it sounds when described calmly in a blog post. If the edit is trivial and the stakes are high, the editor that can’t put you in the wrong mode is sometimes the correct engineering choice, not a concession.

The flags worth knowing

nano -l file.txt         # show line numbers (matters for referencing "line 42" in a change record)
nano -B file.txt         # keep a .bak backup of the original
nano -w file.txt         # disable line wrapping, important for config files where a long ACL
                          # line wrapping mid-screen makes it look like two lines when it isn't

-w matters more than it looks for network configs specifically: a long access-list line or a wrapped route-map statement can visually split across the terminal in a way that’s easy to misread as two separate lines if wrapping is on. Turning it off keeps one logical line as one visual line, scrolling horizontally instead of wrapping.

Search, replace, and moving text

nano’s on-screen footer already tells you the bindings, but the ones that matter for config editing specifically:

• Ctrl-W searches forward.
• Ctrl-\ (or M-R on some builds) is search-and-replace, prompts for the pattern then the replacement, and asks for confirmation on each match by default, which is a genuinely nice safety property sed’s -i doesn’t have without extra scripting.
• Ctrl-K cuts the current line (or the current selection, if one’s marked with Ctrl-^ first) into a buffer; Ctrl-U pastes it. Repeated Ctrl-K on consecutive lines cuts them all into the same buffer, which is nano’s rough equivalent of vim’s registers for moving a small block of config from one place to another in the same file.

$EDITOR, $VISUAL, and why the “wrong” editor sometimes opens

A number of standard Unix tools don’t have their own built-in editor, they shell out to whatever $EDITOR (or $VISUAL, which takes priority when set) points at:

crontab -e
visudo
git commit    (when no -m is given)
sudoedit

If neither variable is set, most of these fall back to vi, which is why crontab -e on a fresh box drops you into vim whether you wanted it or not, and why the “how do I make crontab open nano instead” question is really an $EDITOR question, not a crontab question:

export EDITOR=nano        # for the current shell session
echo 'export EDITOR=nano' >> ~/.bashrc     # persist it

Set it in a shared jump box’s shell profile and every subsequent visudo or crontab -e for every user of that box opens the editor the team has actually standardized on, rather than whatever vi’s default happens to be. sudoedit in particular is worth knowing about regardless of which editor you land in: it edits a temporary copy of a privileged file, then copies the result back with the correct permissions on save, which is a meaningfully different security property from sudo vi /etc/something running an entire editor process as root for the whole session.

The actual decision

vim for anything repetitive, anything scripted, anything that benefits from macros or block editing, or anything on a box where you already live daily and the modal overhead has long since stopped being overhead. nano for a fast one-off edit, for handing instructions to someone else in real time, or for the rare case where the stakes of fumbling a mode transition genuinely outweigh the productivity vim would otherwise offer. Neither choice needs defending to anyone. Part 8 moves from editing single files to comparing two versions of one, before you push a change: diff and patch.