Why I Standardize a Five-Line nanorc on Every Server I Touch

You're SSH'd into a production box at 2 a.m. There's no vim, no VS Code remote session, just nano — because nano is what's installed on the minimal image, the rescue shell, and the container you exec'd into. The default experience is bare: no line numbers, no syntax colors, hard-wrapped lines that mangle long config entries. The good news: a five-line ~/.nanorc fixes most of that, and it's a decision you can make once and copy everywhere.

The case for configuring nano instead of replacing it

The usual instinct is to install a "real" editor. On ephemeral hosts, containers, and locked-down servers, that's friction: package installs may be disallowed, the box may be gone tomorrow, and every minute spent bootstrapping tooling is a minute not spent on the actual problem. Nano is already there, starts instantly, and has no modes to fumble under pressure. Spending two minutes standardizing its config is a better trade than spending ten installing something heavier.

Nano reads /etc/nanorc system-wide and ~/.nanorc per user; the per-user file wins. That split matters: on shared machines you can drop sane defaults in /etc/nanorc (needs root) and let individuals override.

A minimal, defensible ~/.nanorc

Here's the config I treat as a baseline, with what each line actually does:

set linenumbers
set softwrap
set autoindent
set tabstospaces
set tabsize 4
include "/usr/share/nano/*.nanorc"

• set linenumbers — shows line numbers in the left margin. Essential when an error message says "line 147."
• set softwrap — wraps long lines visually without inserting real newlines. Critical for editing configs where a stray newline breaks parsing.
• set autoindent — keeps the previous line's indentation when you press Enter.
• set tabstospaces + set tabsize 4 — Tab inserts four spaces, so you stop fighting YAML and Python files.
• The include line pulls in per-language syntax highlighting rules. Many distributions ship these files but leave the include commented out of the default nanorc.

To apply it: edit ~/.nanorc as your own user (no root needed), save, and open any file — nano reads the config at startup, no reload command needed. Verify with nano --version first, because option names vary across versions, and run ls /usr/share/nano/ to confirm the syntax files actually exist before relying on the include path — it's distribution-specific. If nano rejects an option, it prints an error at startup naming the bad line, so a broken config is loud, not silent.

To check the result: open a shell script or YAML file. You should see line numbers, colored keywords, and long lines wrapped with a visual marker rather than truncated. Edit a line and press Enter to confirm indentation carries over.

The mouse trap and other honest trade-offs

set mouse sounds great — click to place the cursor, drag to select. The catch: once nano captures the mouse, your terminal's native select-to-copy stops working (you'd need to hold Shift in most terminals to bypass it). On a server where half your workflow is copy-pasting log snippets into a ticket, that's a real cost. I leave it off and use Ctrl+6 / Alt+6 for mark-and-copy inside nano instead.

Two more habits worth adopting: nano -v file.conf opens a file read-only (view mode), which is the safe default when you're inspecting a production config rather than editing it — no accidental keystrokes, no risk, nothing to roll back. And set multibuffer lets you open several files and flip between them with Alt+, and Alt+., handy for comparing two configs.

The limitation to be clear-eyed about: nano is still nano. There's no LSP, no project-wide search, no plugin ecosystem. This config makes it a competent tool for quick edits and emergency changes — it does not make it your daily driver, and it shouldn't try to be.

Make it a one-liner in your provisioning

The real payoff comes from treating the nanorc as infrastructure. Drop those six lines into your dotfiles repo, your Ansible role, or your container base image, and every future shell session gets the same sane editor. Next time you're on an unfamiliar box, the editor behaves the way your hands expect — which, at 2 a.m., is worth more than any feature list.