Tim's blog (Posts about cli)

Assorted less(1) tips

Tim Chase — Tue, 11 Nov 2025 15:28:50 GMT

"word to your moms, I came to drop bombs, I've got more less tips than the Bible's got Psalms."

In a recent discussion on Reddit I shared a number of tips about the common utility less(1) that others found helpful so I figured I'd aggregate some of those tips here.

Operating on multiple files

While most folks invoke less at the tail of a pipeline like

$  command | less

Invoking less in a pipeline

you can directly provide one or more files to open

$  less README.txt file.c *.md

Invoking less directly

Adding files after starting

When reading a document, sometimes you want to view another file, adding it to the file list. Perhaps while reading some C source code you want to also look over the corresponding header-file. You can add that header-file to the argument list with :e file.h

Navigating multiple files

You can navigate between multiple files using :n to go to the next file in the argument-list, and :p for the previous file. You can also use :x to rewind to the first file in the argument-list similar to how :rewind behaves in vi/vim.

Removing files after starting

While I rarely feel the need to, if you have finished with a file and want to keep your argument list clean, you can use :d to delete the current file from the argument-list.

Navigating

Jumping to a particular line-number

Use «count»G to jump to a particular line-number. So using 3141G will jump to line 3141. It helps to display line numbers.

Jumping to a particular percentage-offset

Similarly, using «count»% jumps to that percentage-offset of the file. So if you want to go to ¾ of the way through the file, you can type 75% to jump right there.

Searching

While many folks know you can search forward with /«pattern» and some people know you can use ?«pattern» to search backwards, or use n/N to search again for the next/previous match, less provides modifiers you can specify before the pattern to modify its behavior:

!: Find the next line that doesn't match the pattern
*: search across multiple files, starting from the current location in the current file
@: rewind to the first file and search from there
@*: rewind to the first file and search from there across multiple files

Thus you would use /@*«pattern» to search for "pattern" starting with the first file.

Filtering lines

Using & lets you specify a pattern and filter the displayed lines to only those matching the pattern, much like an internal grep command. If you modify it with !, so it will display only those lines that do not match the pattern, like &!«pattern». I find this particularly helpful for browsing log-files.

Bookmarking

You can bookmark points in a file with m followed by a letter, then jump back to that bookmark with ' followed by the same letter. These apply globally across all open files, so if you ma in the third file, then navigate away to other files, using 'a will take you back to the marked location in that third file. I use marks most when reading man-pages, dropping one mark at the OPTIONS section such as mo, and another at the EXAMPLES section, such as me, then bounce back and forth between them with 'o and 'e. While you can use any of the 26 lowercase or uppercase letters (for a total of 52 marks), I rarely use more than two or three either in alphabetical order ("a", "b", "c"), or assigning mnemonics like in the man-page example above.

Bracket matching

If the first line on the screen contains a (, [, or {, typing that character will jump to the matching/closing character, putting it on the bottom line of the screen. Similarly, if a closing ), ], or }, character appears on the last line, typing that closing character will jump to the matching/opening character, putting it at the top of the screen. I find it a little disorienting if they fall less than a screen-height apart because what feels like a forward motion to find the next matching close-bracket might actually result in shifting the screen down rather than up which feels backwards.

While I don't use it much, you can also specify match-pairs using alt+ctrl+f or alt+ctrl+b followed by the opening/closing pair of characters such as alt+ctrl+f<> to define a "<"…">" pair and jump between them in a manner similar to the (/), [/], and {/) motions.

Toggling options without restarting

While the man-page documents many flags you can pass on the command-line, you can also toggle boolean options from inside less. I find this particularly helpful when I've fed the output of a long-running process to less and don't want to re-run it because it will take a long time. Instead of quitting, you can type a literal - followed by the option you want to change. I most commonly want to toggle word-wrap for long lines, so instead of quitting and adding -S at the end of my pipeline, I can type -S directly in less. Options I commonly toggle:

-S: word-wrap (mnemonic "splitting long lines")
-G: search-highlighting
-i/-I: smart-case/case-sensitivity for searches
-R: ANSI-color escaping
-N/-n: show/hide line-numbers

Running external commands

The ! lets you invoke an external command. I don't do this often, but occasionally I want some simple reference like the current date (!date) or to do some simple math (!bc).

Default options with `$LESS`

You might find yourself regularly setting a common group of options so you can put those in your environment (usually in your shell startup file like ~/.bashrc) like LESS="-RNe" if you want to show ANSI colors, show line-numbers, and exit automatically when you reach the end of the file.

Other misc

less has a few other corners that I've never really used, but figured I'd document here:

Editing the current document

The v command will open your $VISUAL editor on the current document.

"Log" output

less lets you redirect the output it has gathered from stdin to a file using the o command (or the O command to overwrite an existing file). This might come in handy because less won't let you edit stdin in an external editor but you can write it directly to a file.

Unsorted ed(1) Tips and Tricks

Tim Chase — Sat, 06 Feb 2016 23:35:09 GMT

Edit text like a pro with ed(1)

I came across Ten unsorted vi/vim tricks, volume one & Ten unsorted vi/vim tricks, volume two

and thought I'd compile a similar list for ed(1).

In this post I will present counterpoints with easy & but useful tricks using ed(1) commands and, in the Unix philosophy, external tools.

You might ask, why ed(1)?

ed(1) is always^* there: Since ed(1) is required by POSIX, you should find it in any *nix/Linux distribution. Sadly, many distros drop ed(1) from their core installations, making it an optional add-on package.
ed(1) is small but mighty: On various systems at my disposal, ed(1) clocks in at between 51k and 183k, while nano is 2-4x as large, vi/vim is 3-20x as large, and emacs lumbers in at over 8 megs. Yet ed(1) provides a lot of functionality in those meager few bytes.
ed(1) needs no configuration: You don't have to worry about sitting down at a foreign machine and not knowing how ed(1) is configured. Yes, there are some subtle differences between GNU ed(1) and BSD ed(1) but the vast majority is the same.

Getting some help

ed(1) is known for its terse ? reply to any issue. You can request in-line help with the h command for a bit of a hint. Additionally, the man page should cover everything you need to know.

s/oof/bar/
?
h
No match

Search and replace

To search, use the / or ? command followed by your search pattern.

/pattern/n
18 this line contains "pattern"

To search and replace on the current line, use the s command:

s/foo/bar/g

or, apply the changes over a range:

4,18s/foo/bar/g

Show line numbers

To show line numbers in ed(1) add the suffix n to your command, for example

,s/foo/bar/n
g/pattern/n
10zn

Execute an external command from within `ed(1)`

Use the ! command to execute

!ls
file.txt
!

Insert an existing file into the current one

In case you need to insert the contents of a file into the one you're currently writing, use the r command.

r file.txt
1625

Note that ed(1) lets you know how many bytes were added to your file.

Display changes performed since last save

This trick uses diff to display the difference between the file on disk and the current editing buffer.

w !diff -u file.txt -

Indendent and un-indenting lines

To indent a range of lines, substitute the beginning of the line with either spaces or tabs:

12,18s/^/    /
.,+4s/^/{tab}/

To unindent, strip off that number of leading indentation:

12,18s/^    //
12,18s/^ \{4\}//
.,+4s/^{tab}//

Undo & redo

ed(1) provides one level of undo/redo, using the u command to toggle between them:

$ ed
1a
hello
world
.
2d
,n
1 hello
u
,n
1 hello
2 world
u
,n
1 hello
Q

Insert the output of an external command

Similar to the insertion of a file above, ed(1) lets you use the r ! command to read the output of an external program:

r !ls -l

Record commands

(you can do this with rlwrap but a bug in rlwrap caused repeated segfaults)

Command history

Since ed(1) appends to the terminal window rather than overwriting and redrawing the screen, the entire editing history for the given ed(1) session is available for review.

Using ed(1) as a password manager

Tim Chase — Fri, 06 Nov 2015 21:36:29 GMT

I recently came across a post on using vim as a password manager so I thought I'd post a companion article on using ed(1) as a password manager.

The main goal is to be able to keep the secrets encrypted at all times on disk, only decrypting within the active ed(1) session.

BSD ed(1) offers an x command (well, OpenBSD removed it in revision 1.37 of /src/bin/ed/main.c "because DES") that allows for weak DES encryption of the file. However, we want stronger encryption and portability between various versions of ed(1) so will ignore this option.

Writing our encrypted password file to disk

To begin, we'll open up ed(1) and add some password content

user@hostname$ ed
a
https://example.com
Username: demo
Password: Pa$$w0rd1

imaps://example.edu
Username: jstudent@example.edu
Password: ed(1)uc8

.

Now, instead of writing the unencrypted password file, we'll use gnupg to encrypt the file and write it out to the disk by piping the file through gpg instructing it to write to our password file. Note the trailing "-" which tells gpg to read the input from stdin. gpg will prompt for a passphrase and confirmation of that password.

w !gpg --symmetric --output passwords.gpg -
Enter passphrase: Password1
Repeat passphrase: Password1
127

ed(1) informs us that it successfully piped our 127 bytes of data through gpg but we can confirm that the passwords.gpg file was written and then we can quit to go about our day:

!ls passwords.gpg
passwords.gpg
!
q

Reading our encrypted password file from disk

Now, we want to be able to look up a password to enter at some future point. So we fire up ed(1) and decrypt our passwords.

user@hostname$ ed
r !gpg --decrypt passwords.gpg
Enter passphrase: Password1

We want to look up our log-in credentials for our email server so we issue

?imap.*edu
imaps://example.edu
+
Username: jstudent@example.edu
+
Password: ed(1)uc8
Q

(Yes, using "+" can be replaced with just hitting "<Enter>") Alternatively, we could use grep(1) or sed(1) to filter the results and show some context:

user@hostname$ gpg --decrypt passwords.gpg | grep -A2 example.com
Enter passphrase: Password1
https://example.com
Username: demo
Password: Pa$$w0rd1
user@hostname$ gpg --decrypt passwords.gpg | sed -n '/example.com/,/^$/p'
Enter passphrase: Password1
https://example.com
Username: demo
Password: Pa$$w0rd1

Modifying our password lists

Now we want to modify our document and/or change our master-password:

user@hostname$ ed
r !gpg --decrypt passwords.gpg
Enter passphrase: Password1
127
3s/Pa..w0rd1/Pbuttwrd1
Password: Pbuttwrd1
$a
https://twitter.com/
Username: ed1conf
Password: EyeDonutThinkSew

.
w !gpg --symmetric --output passwords.gpg -
Enter passphrase: NewPassword2
Repeat passphrase: NewPassword2
File `passwords.gpg` exists. Overwrite? (y/N) y
194

And there you have it: using ed(1) as a password manager.

Why ed(1)?

Tim Chase — Thu, 10 Sep 2015 01:55:08 GMT

As the weirdo behind the somewhat tongue-in-cheek @ed1conf account on Twitter and Mastodon, account I'm occasionally asked "Why ed(1)?" Hopefully some of my reasons for learning & using ed(1) can pique your interest in taking the time to get to know this little piece of history.

Ubiquity

Sometimes your favorite $EDITOR is installed, sometimes it's not. Some, like vi/vim are just about everywhere. Other times, you would have to have sufficient privileges/space to install or compile your editor of choice. But if you know ed, nearly every Linux/BSD/Mac has it installed because it's part of the POSIX standard. It's even small enough to fit on most recovery media without breaking the bank. But between ed and vi/vim, I know that I can get things done even when I'm on a new machine.

Sometimes it's the only editor you have

Several times in my life ed has been the only editor available in certain environments.

At $DAYJOB[-1] the Linux-based router needed some configuration changes that the web interface didn't accommodate. So a quick terminal connection later (telnet, sigh), I discovered that ed was the only editor available. No problem. Edited the config file and we were back up and running with the proper changes.
At the same $DAYJOB[-1], I developed software for a ruggedized hand-held device and its attached printer. This was back when PDAs were just becoming popular, so this thing was a brick. The DOS-based operating system had no built-in editor, meaning editing files usually meant laboriously copying the file over a serial link to the PC, editing it there, then sending it back down. I longed for the ability to cut that time down but very few of the full-screen editors I tried were even able to successfully paint on the small LCD screen-buffer properly, and of those that did, the on-screen keyboard took up so much screen real-estate as to make them useless. So I installed a DOS build of ed and it worked like a charm (better than edlin.exe that I also tried). Editing turn-around and testing went from 15-20 minutes down to 3-5 minutes per iteration.
Some platforms such as Heroku provide only ed as their editor. Not usually an issue since most of the time you're not trying to edit live on the server. But if you need to do it, it's nice to know how.
On some MUD games and old BBSes, the text-editor is often an ed-like editor.

Visible editing history

Unless you have a key-echoing utility like Screenkey or Screenflick, it's hard for an audience to see exactly what you did when you're editing during a presentation. It's nice to for the audience to be able to see exactly what you typed if they're trying to follow along.

All commands are ASCII text

Sometimes your terminal emulator or keyboard isn't configured correctly. Function keys, arrows, alt- and meta-modifiers may not transmit properly. Since all of ed's commands are basic ASCII, it works even if your keyboard/terminal is unable to send extended characters properly.

It works when `$TERM` is messed up

Likewise, your $TERM setting can get messed up. Sometimes full-screen terminal applications leave the screen in a state where everything is somewhat garbled. Yes, there's reset which will let you reset the terminal back to some sensible defaults, but sometimes your termcap database has trouble too. An editor that only uses stdin and stdout can save your bacon.

Accessibility

Because ed reads all of its commands from stdin and writes all output to stdout in a serial fashion, it's very usable in a screen-reader like yasr or speakup allowing you to edit text without a screen. If you've never edited text sightless, give it a try some time.

Scriptability

Because ed reads all of its commands from stdin it's easy to write a script that will edit a file in an automated fashion.

Previous output

On occasion, I want to see the output of one or more previous shell commands while I continue to edit. A full-screen editor takes over the entire screen, preventing me from seeing that output. With ed the previous output is right there and remains in my scroll-back buffer for reference while I edit. I find this particularly useful when using \e in psql or mysql if my $EDITOR is set to ed. This allows me to edit the SQL while keeping the results of my previous query visible.

Small, fast, light

On resource-constrained systems, sometimes you need something light like ed where the executable and memory-footprint are measured in kilobytes rather than megabytes. This is less of a problem on most systems these days, but with small resource-constrained SOC and embedded boards running Linux or BSD, a light-weight yet powerful editor can help.

Usable on low-bandwidth/high-latency connections

Sometimes you are connected by a slow or very laggy connection. Whether this is a satellite uplink, a 300-baud serial connection, or a congested WAN link, sometimes you simply want to edit productively without the overhead of repainting the screen.

Showing off

Finally, there's a small measure of grey-beard prestige that comes with using an editor that baffles so many people. It's a fast way to demonstrate that I'm not some newbie with cert-only knowledge, but that I enjoy Unix history and working at the command-line. Or maybe it shows that I'm just a little crazy.

Tim's blog (Posts about cli)

Assorted less(1) tips

Operating on multiple files

Adding files after starting

Navigating multiple files

Removing files after starting

Navigating

Jumping to a particular line-number

Jumping to a particular percentage-offset

Searching

Filtering lines

Bookmarking

Bracket matching

Toggling options without restarting

Running external commands

Default options with $LESS

Other misc

Tags

Editing the current document

"Log" output

Unsorted ed(1) Tips and Tricks

Edit text like a pro with ed(1)

Getting some help

Search and replace

Show line numbers

Execute an external command from within ed(1)

Insert an existing file into the current one

Display changes performed since last save

Indendent and un-indenting lines

Undo & redo

Insert the output of an external command

Record commands

Command history

Using ed(1) as a password manager

Writing our encrypted password file to disk

Reading our encrypted password file from disk

Modifying our password lists

Why ed(1)?

Ubiquity

Sometimes it's the only editor you have

Visible editing history

All commands are ASCII text

It works when $TERM is messed up

Accessibility

Scriptability

Previous output

Small, fast, light

Usable on low-bandwidth/high-latency connections

Showing off

Default options with `$LESS`

Execute an external command from within `ed(1)`

It works when `$TERM` is messed up