Change text without wrecking the file

The single most useful recovery key in vi is u. Made a mess? Press Esc, then u until the file looks right again. vim keeps a long undo history, so you are rarely more than a few presses from where you started. Here is a small edit run: fix a typo, delete a stray line, and undo one step.

# cursor on the wrong character
x            # delete it
i            # enter Insert mode
z            # type the correct character
<Esc>        # back to Normal mode
dd           # delete the whole line the cursor sits on
u            # changed your mind, undo the delete
:w           # write the file, output at the bottom:
"notes.txt" 12L, 214B written

Save, quit, and the gap between 😡 and :wq

Write and quit are separate ideas in vi, which is why one command to save and a different one to leave trips people up. The table below is the set worth memorising. Note the quiet difference at the bottom: :x writes only if the buffer changed, while :wq always writes and bumps the file timestamp even when nothing changed. On a system where a config change triggers a file watcher, that stray timestamp can matter.

The vim-tiny trap on a fresh Ubuntu box

Here is a real one that costs beginners an afternoon. You SSH into a fresh Ubuntu server, open a file, enter Insert mode, and press an arrow key to move. Instead of moving, vi types the letters A, B, C, or D into your file. Nothing is broken. That server has vim-tiny, which starts in compatible mode where the arrow keys are not wired for Insert mode, so the terminal escape sequence for each arrow leaks through as a letter.

Editing a file you do not own

You open /etc/hosts, make your edit, type :wq, and vi refuses with E45: readonly option is set, or the write fails because you forgot sudo. You do not have to lose the edit and start over. Ask vi to hand the buffer to a privileged helper:

:w !sudo tee % > /dev/null
[sudo] password for admin:
# vim then warns the file changed on disk, press L to reload

Reading it out: :w !cmd pipes the buffer to a shell command, sudo tee writes that stream to a file with root rights, % expands to the current filename, and > /dev/null drops the copy tee would otherwise echo back. It fails only if the file carries an immutable flag, which you clear with sudo chattr -i /path first. The cleaner habit for planned edits is sudoedit /etc/hosts, which opens a temporary copy and installs it with the right privileges on save.

One full rescue, start to finish

Put it together the way it happens on a real box. You need to add a hostname to /etc/hosts on a server you reached over SSH, and you opened the file without sudo.

$ vi /etc/hosts
# file opens, cursor on line 1, Normal mode
G            # jump to the last line
o            # open a new line below and enter Insert mode
10.0.0.42 db01.internal
<Esc>        # back to Normal mode
:wq
E45: 'readonly' option is set (add ! to override)
# right, no write permission. do not panic, do not retype
:w !sudo tee % > /dev/null
[sudo] password for admin:
1 line, 24 bytes
# press L when vim asks, then
:q!          # buffer already saved through tee, quit the view

The failure mode to expect: if you type :wq! instead of the tee line, vi still cannot write and you get the same readonly error with a bang. The exclamation mark overrides vi rules, not Linux file permissions. Only a privileged writer, sudo tee or sudoedit, gets past the permission bits.

When vim warns about a swap file

Open a file and sometimes vim greets you with a wall of red text and E325: ATTENTION. It looks like the file is damaged. It is not. While you edit, vim keeps a hidden swap file next to the original, named like .hosts.swp, so it can rescue your work if the session dies. When an SSH connection drops or a laptop sleeps mid-edit, that swap file is left behind, and the next open notices it and asks what to do.

E325: ATTENTION
Found a swap file by the name ".hosts.swp"
          owned by: admin   dated: Fri Jul  3 09:14:20 2026
While opening file /etc/hosts
(1) Another program may be editing the same file.
(2) An edit session for this file crashed.
Swap file ".hosts.swp" already exists!
[O]pen Read-Only, (E)dit anyway, (R)ecover, (D)elete it, (Q)uit, (A)bort:

Read the two lines that matter. If the swap file is dated from a session that crashed, press R to recover, and vim rebuilds the file from the swap so you keep the edits that were open when it died. Save the recovered version with :w, then delete the leftover swap file from the shell so the warning stops. If you know the swap is stale and there is nothing to save, press D to delete it and open clean. The one answer to avoid is pressing E to edit anyway on a file another admin is actively editing, because now two sessions can overwrite each other on save. When in doubt, recover, look, then decide.

# recover from the shell without the prompt
$ vim -r /etc/hosts
:w recovered-hosts
:q
# then clear the stale swap so the next open is clean
$ ls -a /etc/ | grep swp
.hosts.swp
$ sudo rm /etc/.hosts.swp

Myth versus reality

Where this goes next

Editing files by hand is the step before you stop editing them by hand. Once these keys are automatic, you will reach for vi to fix a crontab, a systemd unit, or a shell script without thinking about the editor at all. That is the goal: the tool disappears and the task is all that is left. Next in the series is scheduling work with cron, where you will edit those job files with exactly the keys from this part. If you are building toward a wider role, the same command-line reflexes carry into Cloud for Beginners and VMware for Beginners. Open a throwaway file today and quit it five different ways until none of them make you pause.

References

• Ubuntu bug 491615: arrow keys in vim-tiny Insert mode
• nixCraft: fix vim arrow keys inserting A B C D over SSH
• nixCraft: save a file in vi without root permission
• catonmat: how the sudo tee write trick works

One habit saves you every time: when you are not sure what mode you are in, press Esc once or twice. A beep just means you were already in Normal mode. In Insert mode, full vim prints -- INSERT -- at the bottom left, so glance there before you start typing.

Open a file and move around

Movement happens in Normal mode. The four keys under your right hand are h left, j down, k up, and l right. They feel wrong for a day and then vanish into habit. Bigger jumps save real time: w hops forward one word, b back one word, 0 goes to the start of the line, $ to the end, gg to the top of the file, and G to the bottom. Turn on line numbers with :set number so error messages that name a line actually help you.

Change text without wrecking the file

The single most useful recovery key in vi is u. Made a mess? Press Esc, then u until the file looks right again. vim keeps a long undo history, so you are rarely more than a few presses from where you started. Here is a small edit run: fix a typo, delete a stray line, and undo one step.

# cursor on the wrong character
x            # delete it
i            # enter Insert mode
z            # type the correct character
<Esc>        # back to Normal mode
dd           # delete the whole line the cursor sits on
u            # changed your mind, undo the delete
:w           # write the file, output at the bottom:
"notes.txt" 12L, 214B written

Save, quit, and the gap between 😡 and :wq

Write and quit are separate ideas in vi, which is why one command to save and a different one to leave trips people up. The table below is the set worth memorising. Note the quiet difference at the bottom: :x writes only if the buffer changed, while :wq always writes and bumps the file timestamp even when nothing changed. On a system where a config change triggers a file watcher, that stray timestamp can matter.

The vim-tiny trap on a fresh Ubuntu box

Here is a real one that costs beginners an afternoon. You SSH into a fresh Ubuntu server, open a file, enter Insert mode, and press an arrow key to move. Instead of moving, vi types the letters A, B, C, or D into your file. Nothing is broken. That server has vim-tiny, which starts in compatible mode where the arrow keys are not wired for Insert mode, so the terminal escape sequence for each arrow leaks through as a letter.

Editing a file you do not own

You open /etc/hosts, make your edit, type :wq, and vi refuses with E45: readonly option is set, or the write fails because you forgot sudo. You do not have to lose the edit and start over. Ask vi to hand the buffer to a privileged helper:

:w !sudo tee % > /dev/null
[sudo] password for admin:
# vim then warns the file changed on disk, press L to reload

Reading it out: :w !cmd pipes the buffer to a shell command, sudo tee writes that stream to a file with root rights, % expands to the current filename, and > /dev/null drops the copy tee would otherwise echo back. It fails only if the file carries an immutable flag, which you clear with sudo chattr -i /path first. The cleaner habit for planned edits is sudoedit /etc/hosts, which opens a temporary copy and installs it with the right privileges on save.

One full rescue, start to finish

Put it together the way it happens on a real box. You need to add a hostname to /etc/hosts on a server you reached over SSH, and you opened the file without sudo.

$ vi /etc/hosts
# file opens, cursor on line 1, Normal mode
G            # jump to the last line
o            # open a new line below and enter Insert mode
10.0.0.42 db01.internal
<Esc>        # back to Normal mode
:wq
E45: 'readonly' option is set (add ! to override)
# right, no write permission. do not panic, do not retype
:w !sudo tee % > /dev/null
[sudo] password for admin:
1 line, 24 bytes
# press L when vim asks, then
:q!          # buffer already saved through tee, quit the view

The failure mode to expect: if you type :wq! instead of the tee line, vi still cannot write and you get the same readonly error with a bang. The exclamation mark overrides vi rules, not Linux file permissions. Only a privileged writer, sudo tee or sudoedit, gets past the permission bits.

When vim warns about a swap file

Open a file and sometimes vim greets you with a wall of red text and E325: ATTENTION. It looks like the file is damaged. It is not. While you edit, vim keeps a hidden swap file next to the original, named like .hosts.swp, so it can rescue your work if the session dies. When an SSH connection drops or a laptop sleeps mid-edit, that swap file is left behind, and the next open notices it and asks what to do.

E325: ATTENTION
Found a swap file by the name ".hosts.swp"
          owned by: admin   dated: Fri Jul  3 09:14:20 2026
While opening file /etc/hosts
(1) Another program may be editing the same file.
(2) An edit session for this file crashed.
Swap file ".hosts.swp" already exists!
[O]pen Read-Only, (E)dit anyway, (R)ecover, (D)elete it, (Q)uit, (A)bort:

Read the two lines that matter. If the swap file is dated from a session that crashed, press R to recover, and vim rebuilds the file from the swap so you keep the edits that were open when it died. Save the recovered version with :w, then delete the leftover swap file from the shell so the warning stops. If you know the swap is stale and there is nothing to save, press D to delete it and open clean. The one answer to avoid is pressing E to edit anyway on a file another admin is actively editing, because now two sessions can overwrite each other on save. When in doubt, recover, look, then decide.

# recover from the shell without the prompt
$ vim -r /etc/hosts
:w recovered-hosts
:q
# then clear the stale swap so the next open is clean
$ ls -a /etc/ | grep swp
.hosts.swp
$ sudo rm /etc/.hosts.swp

Myth versus reality

Where this goes next

Editing files by hand is the step before you stop editing them by hand. Once these keys are automatic, you will reach for vi to fix a crontab, a systemd unit, or a shell script without thinking about the editor at all. That is the goal: the tool disappears and the task is all that is left. Next in the series is scheduling work with cron, where you will edit those job files with exactly the keys from this part. If you are building toward a wider role, the same command-line reflexes carry into Cloud for Beginners and VMware for Beginners. Open a throwaway file today and quit it five different ways until none of them make you pause.

References

• Ubuntu bug 491615: arrow keys in vim-tiny Insert mode
• nixCraft: fix vim arrow keys inserting A B C D over SSH
• nixCraft: save a file in vi without root permission
• catonmat: how the sudo tee write trick works

You SSH into a server to fix one line in /etc/hosts. The system drops you into vi. You type your change, the screen does something you did not ask for, and when you try to leave it just beeps at you. Every admin has been trapped in that editor at least once. The fix is smaller than the panic suggests: about a dozen keystrokes open a file, change it, save it, and get you out.

Why this old editor is on every server

vi dates to 1976. vim, the version almost everyone actually runs, arrived in 1991 and stands for vi improved. A minimal server has no desktop, no mouse, and often no editor you chose. On the RHEL family, /bin/vi is provided by the vim-minimal package and is there the moment the box boots. On Debian and Ubuntu, vi resolves to vim-tiny on a stripped image. The point is the same either way: when a service is down and you cannot reach the package mirror, the editor already on disk is the one you get.

Common advice says skip vi and install nano, and on your own laptop that is fine. On a client box at 2am with outbound traffic blocked, you do not get to install anything. That is the case for learning vi and I will stand behind it: the editor you can count on is the one worth the muscle memory, even if nano is friendlier on day one.

Three modes, and every bit of confusion traces to one

The reason keystrokes seem to do random things is that vi has modes, and the same key means different things in each one. There are three that matter. You land in Normal mode, where letters are commands, not text. Press i and you enter Insert mode, where letters are typed into the file. Press : from Normal mode and you drop to the Command line at the bottom, where you save and quit. Esc always takes you back to Normal mode. Here is the full loop as a keystroke trace:

vi notes.txt      # opens in Normal mode
i                 # switch to Insert mode, now you can type
hello world       # this text goes into the file
<Esc>             # back to Normal mode
:w                # write (save) the file
:q                # quit
# or combine the last two as :wq

One habit saves you every time: when you are not sure what mode you are in, press Esc once or twice. A beep just means you were already in Normal mode. In Insert mode, full vim prints -- INSERT -- at the bottom left, so glance there before you start typing.

Open a file and move around

Movement happens in Normal mode. The four keys under your right hand are h left, j down, k up, and l right. They feel wrong for a day and then vanish into habit. Bigger jumps save real time: w hops forward one word, b back one word, 0 goes to the start of the line, $ to the end, gg to the top of the file, and G to the bottom. Turn on line numbers with :set number so error messages that name a line actually help you.

Change text without wrecking the file

The single most useful recovery key in vi is u. Made a mess? Press Esc, then u until the file looks right again. vim keeps a long undo history, so you are rarely more than a few presses from where you started. Here is a small edit run: fix a typo, delete a stray line, and undo one step.

# cursor on the wrong character
x            # delete it
i            # enter Insert mode
z            # type the correct character
<Esc>        # back to Normal mode
dd           # delete the whole line the cursor sits on
u            # changed your mind, undo the delete
:w           # write the file, output at the bottom:
"notes.txt" 12L, 214B written

Save, quit, and the gap between 😡 and :wq

Write and quit are separate ideas in vi, which is why one command to save and a different one to leave trips people up. The table below is the set worth memorising. Note the quiet difference at the bottom: :x writes only if the buffer changed, while :wq always writes and bumps the file timestamp even when nothing changed. On a system where a config change triggers a file watcher, that stray timestamp can matter.

The vim-tiny trap on a fresh Ubuntu box

Here is a real one that costs beginners an afternoon. You SSH into a fresh Ubuntu server, open a file, enter Insert mode, and press an arrow key to move. Instead of moving, vi types the letters A, B, C, or D into your file. Nothing is broken. That server has vim-tiny, which starts in compatible mode where the arrow keys are not wired for Insert mode, so the terminal escape sequence for each arrow leaks through as a letter.

Editing a file you do not own

You open /etc/hosts, make your edit, type :wq, and vi refuses with E45: readonly option is set, or the write fails because you forgot sudo. You do not have to lose the edit and start over. Ask vi to hand the buffer to a privileged helper:

:w !sudo tee % > /dev/null
[sudo] password for admin:
# vim then warns the file changed on disk, press L to reload

Reading it out: :w !cmd pipes the buffer to a shell command, sudo tee writes that stream to a file with root rights, % expands to the current filename, and > /dev/null drops the copy tee would otherwise echo back. It fails only if the file carries an immutable flag, which you clear with sudo chattr -i /path first. The cleaner habit for planned edits is sudoedit /etc/hosts, which opens a temporary copy and installs it with the right privileges on save.

One full rescue, start to finish

Put it together the way it happens on a real box. You need to add a hostname to /etc/hosts on a server you reached over SSH, and you opened the file without sudo.

$ vi /etc/hosts
# file opens, cursor on line 1, Normal mode
G            # jump to the last line
o            # open a new line below and enter Insert mode
10.0.0.42 db01.internal
<Esc>        # back to Normal mode
:wq
E45: 'readonly' option is set (add ! to override)
# right, no write permission. do not panic, do not retype
:w !sudo tee % > /dev/null
[sudo] password for admin:
1 line, 24 bytes
# press L when vim asks, then
:q!          # buffer already saved through tee, quit the view

The failure mode to expect: if you type :wq! instead of the tee line, vi still cannot write and you get the same readonly error with a bang. The exclamation mark overrides vi rules, not Linux file permissions. Only a privileged writer, sudo tee or sudoedit, gets past the permission bits.

When vim warns about a swap file

Open a file and sometimes vim greets you with a wall of red text and E325: ATTENTION. It looks like the file is damaged. It is not. While you edit, vim keeps a hidden swap file next to the original, named like .hosts.swp, so it can rescue your work if the session dies. When an SSH connection drops or a laptop sleeps mid-edit, that swap file is left behind, and the next open notices it and asks what to do.

E325: ATTENTION
Found a swap file by the name ".hosts.swp"
          owned by: admin   dated: Fri Jul  3 09:14:20 2026
While opening file /etc/hosts
(1) Another program may be editing the same file.
(2) An edit session for this file crashed.
Swap file ".hosts.swp" already exists!
[O]pen Read-Only, (E)dit anyway, (R)ecover, (D)elete it, (Q)uit, (A)bort:

Read the two lines that matter. If the swap file is dated from a session that crashed, press R to recover, and vim rebuilds the file from the swap so you keep the edits that were open when it died. Save the recovered version with :w, then delete the leftover swap file from the shell so the warning stops. If you know the swap is stale and there is nothing to save, press D to delete it and open clean. The one answer to avoid is pressing E to edit anyway on a file another admin is actively editing, because now two sessions can overwrite each other on save. When in doubt, recover, look, then decide.

# recover from the shell without the prompt
$ vim -r /etc/hosts
:w recovered-hosts
:q
# then clear the stale swap so the next open is clean
$ ls -a /etc/ | grep swp
.hosts.swp
$ sudo rm /etc/.hosts.swp

Myth versus reality

Where this goes next

Editing files by hand is the step before you stop editing them by hand. Once these keys are automatic, you will reach for vi to fix a crontab, a systemd unit, or a shell script without thinking about the editor at all. That is the goal: the tool disappears and the task is all that is left. Next in the series is scheduling work with cron, where you will edit those job files with exactly the keys from this part. If you are building toward a wider role, the same command-line reflexes carry into Cloud for Beginners and VMware for Beginners. Open a throwaway file today and quit it five different ways until none of them make you pause.

References

• Ubuntu bug 491615: arrow keys in vim-tiny Insert mode
• nixCraft: fix vim arrow keys inserting A B C D over SSH
• nixCraft: save a file in vi without root permission
• catonmat: how the sudo tee write trick works

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts