Terminal Text Editors: Nano and Vim

Many servers do not have a graphical desktop. When you connect over SSH and need to adjust a configuration file, write a short note, or inspect a cron entry, you need a terminal editor. Nano is easy to learn because text entry works normally. Vim is modal, which is harder at first but efficient once the basic commands are familiar.

The editor is only one part of safe administration. Before editing an important file, make a backup. After editing, verify both the file content and the service-specific syntax before reloading anything. The examples below use only ~/lab/editor.

Prepare a Safe Editing Lab

mkdir -p ~/lab/editor
printf 'server_name=demo\nport=8080\nmode=test\n' > ~/lab/editor/app.conf
cp -a ~/lab/editor/app.conf ~/lab/editor/app.conf.bak
ls -l ~/lab/editor/app.conf*

Expected output:

-rw-r--r-- ... /home/<username>/lab/editor/app.conf
-rw-r--r-- ... /home/<username>/lab/editor/app.conf.bak

The backup exists before any edit. That is the habit to keep.

Nano: Direct Editing

Open the lab file:

nano ~/lab/editor/app.conf

Nano shows the file in the main area and key hints at the bottom. In Nano notation, ^ means Ctrl, and M- means Meta, usually Alt. ^O means Ctrl+O, not the characters ^ and O.

Common Nano keys:

Open at a specific line:

nano +2,1 ~/lab/editor/app.conf

This places the cursor at line 2, column 1 on GNU Nano. Check nano --help or man nano on the target system if a shortcut behaves differently; Nano key bindings have changed across versions.

Nano Practice

Inside Nano:

1. Change port=8080 to port=9090.
2. Search for mode.
3. Change mode=test to mode=staging.
4. Save with Ctrl+O, confirm with Enter, then exit with Ctrl+X.

Verify in the shell:

cat ~/lab/editor/app.conf

Expected content:

server_name=demo
port=9090
mode=staging

To roll back:

cp -a ~/lab/editor/app.conf.bak ~/lab/editor/app.conf
cat ~/lab/editor/app.conf

Vim and Vi: Modal Editing

vi is the traditional Unix editor interface. Vim, "Vi Improved", adds many features while keeping Vi-style commands. On some distributions, vi is a small Vim build; on others it may be a different Vi-compatible editor.

Check what you have:

command -V vi
command -V vim
vi --version | head -n 1

If vim is not available, use vi for the basic commands in this article.

Open a copy:

cp -a ~/lab/editor/app.conf.bak ~/lab/editor/vim.conf
vi ~/lab/editor/vim.conf

The Three Modes Beginners Need

Most Vim confusion comes from modes:

• Normal mode: navigation, deletion, copy, paste, search, and commands. Vim starts here.
• Insert mode: text entry. Enter it with i, a, or o.
• Command-line mode: saving, quitting, settings, and help. Enter it from Normal mode with :.

If you are unsure where you are, press Esc. That returns to Normal mode in normal situations.

Normal -- i/a/o --> Insert
Insert -- Esc ----> Normal
Normal -- : ------> Command-line

Minimal Vim Commands

Normal mode movement:

Editing:

Command-line mode:

• :w: write the file.
• :q: quit if there are no unsaved changes.
• :wq: write and quit.
• :q!: quit and discard unsaved changes.
• :set number: show line numbers.
• :15: jump to line 15.
• :help :write: open help for :write.

Saving Without Write Permission

If you open a file you cannot write to and try to save, Vim tells you directly rather than saving silently or crashing:

E212: Can't open file for writing

This appears on the command line at the bottom of the screen after :w. It means exactly what it says: the process editing the file does not have write permission on that path. Common causes, in order of likelihood:

• you opened the file as a regular user but it is owned by root or another service account;
• the directory itself, not just the file, denies write (renaming a file during save requires write access to its parent directory);
• the filesystem is mounted read-only.

Check which one applies before reaching for sudo:

ls -l -- <file>
ls -ld -- "$(dirname -- <file>)"
mount | grep -w "$(df --output=target -- <file> | tail -n 1)"

If the file genuinely requires elevated privilege, the safer pattern is to reopen it with sudo, not to fight the running instance:

:w !sudo tee % > /dev/null

This writes the buffer through sudo tee back into the same filename (% is the current filename in Vim) without restarting the editor and losing your unsaved changes. Confirm the result afterward with cat or diff against your backup, the same as any other privileged edit.

Vim Practice

Inside vi ~/lab/editor/vim.conf:

1. Press /port, then Enter, to find the port line.
2. Press 0 to move to the start of the line.
3. Move to 8080, then press cw9090, then Esc.
4. Run :set number.
5. Run :wq.

Verify:

cat ~/lab/editor/vim.conf
cat ~/lab/editor/app.conf.bak

Only the planned value should differ. In later text-processing lessons, tools such as diff make this comparison precise; for now, the key workflow is backup, edit, inspect, and validate.

To practice Vim safely:

vimtutor

If vimtutor is not installed, use the built-in help from inside Vim or Vi with :help.

Read-Only Viewing

If you only want to inspect a small file, use a viewer:

cat ~/lab/editor/app.conf

For editor-based read-only intent:

view ~/lab/editor/app.conf
vi -R ~/lab/editor/app.conf

Read-only mode is a guardrail, not a security boundary. It can often be overridden from inside the editor if the process has permission to write. If you truly must avoid changes, use cat, less, or a copied file.

Swap Files and Concurrent Editing

Vim may warn about a swap file when the same file appears to be open elsewhere or a previous edit crashed. Do not delete the swap file automatically.

The warning is a full-screen prompt, not a one-line message, and it looks like this:

E325: ATTENTION
Found a swap file by the name ".app.conf.swp"
          owned by: admin   dated: Tue Jul 29 10:15:03 2026
         file name: ~admin/lab/editor/app.conf
          modified: YES
         user name: admin   host name: web01
        process ID: 18422
While opening file "app.conf"
             dated: Tue Jul 29 10:12:40 2026

(1) Another program may be editing the same file.  If this is the case,
    be careful not to end up with two different instances of the same
    file when making changes.  Quit, or continue with caution.
(2) An edit session for this file crashed.
    If this is the case, use ":recover" or "vim -r app.conf"
    to recover the changes (see ":help recovery").
    If you did this already, delete the swap file ".app.conf.swp"
    to avoid this message.

Swap file ".app.conf.swp" already exists!
[O]pen Read-Only, (E)dit anyway, (R)ecover, (Q)uit, (D)elete it, (A)bort:

Read the two numbered paragraphs before choosing a letter — they are Vim telling you exactly which of the two situations you are in. The last line is the actual prompt:

• O (Open Read-Only) — safest default when you are not sure. You can inspect the file without risking a second writer.
• E (Edit anyway) — proceed knowing another process, or you in another terminal, may already hold this file open. Two writers can silently overwrite each other's changes on save.
• R (Recover) — same as running vim -r <file> directly; Vim replays the swap file's changes into a new buffer so you can inspect and re-save what was lost when the previous session crashed.
• D (Delete it) — only correct once you have confirmed, via ps or by asking your team, that no other live session owns the file and that you do not need the recovery data. Deleting first and asking questions later can permanently discard someone else's unsaved work.
• Q (Quit) / A (Abort) — back out and investigate before touching anything.

Check before answering:

• Is another terminal still editing the file? (ps -ef | grep -- "vi[m]* .*app.conf" on the same host, or ask whoever else has access.)
• Did a previous session crash with unsaved changes? The process ID line in the prompt tells you which PID owned the session — ps -p <pid> shows whether that process still exists.
• Do you need recovery with vi -r <file>?

If unsure, quit (Q) without editing. Removing an old swap file is safe only after you know no active editor owns it and no recovery data is needed.

Practical Scenario: Change One Configuration Value

Problem: a service port needs to change from 8080 to 9090. The service is fictional, so the validation is simple and local.

Create and back up:

config="$HOME/lab/editor/app.conf"
cp -a -- "$config" "$config.before-port-change"
cat "$config.before-port-change"

Edit only the port line in Nano or Vim.

Verify the result:

cat "$config"
grep -n '^port=[0-9][0-9]*$' "$config"

Expected verification:

2:port=9090

Rollback if needed:

cp -a -- "$config.before-port-change" "$config"
cat "$config"

In production, replace the simple grep check with the real validator: nginx -t, sshd -t, systemd-analyze verify, an application config test command, or a dry-run provided by the software.

Common Mistakes

• Typing Nano hints such as ^O literally instead of pressing Ctrl+O.
• Forgetting to save in Nano after changing text.
• Trying to type in Vim while still in Normal mode.
• Using :q in Vim when there are unsaved changes; use :wq to save or :q! to discard.
• Editing production files without a backup and validation command.
• Ignoring Vim swap warnings without checking for another active session.
• Assuming read-only editor mode is the same as filesystem permission protection.

Exercises

1. Use Nano to change mode=test to mode=dev, save, exit, and verify with cat.
2. Restore the backup, then use Vi or Vim to change only the port line.
3. Open the file with view and confirm how the editor indicates read-only mode.
4. Run vimtutor if available and complete at least the first movement and insert sections.

Verification criterion: you should be able to make one planned edit, prove what changed, and roll it back from a backup.

References

• GNU Nano manual: https://www.nano-editor.org/dist/latest/nano.html
• Ubuntu nano(1) manual page: https://manpages.ubuntu.com/manpages/noble/man1/nano.1.html
• Vim documentation index: https://vimhelp.org/
• Vim first steps: https://vimhelp.org/usr_02.txt.html
• Ubuntu vim(1) manual page: https://manpages.ubuntu.com/manpages/noble/man1/vim.1.html