SHARE

Bash Command Line Shortcuts

I’ve been using bash for years, and I still haven’t come anywhere close to mastering the full range of available command line keyboard shortcuts. I’ve found the best way to get more under my fingers is to note a few on a Post-It stuck to the monitor, and then swap it for another one at […]

Written By

Juliet Kemp

Oct 15, 2008

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

I’ve been using bash for years, and I still haven’t come anywhere close to mastering the full range of available command line keyboard shortcuts. I’ve found the best way to get more under my fingers is to note a few on a Post-It stuck to the monitor, and then swap it for another one at intervals.

Here, are a few useful candidates.

(C = control key, M = alt/meta key.)

C-r and C-s : Launch an incremental search backward and forward (respectively), in your command-line history.
C-j and C-g : Abandon an incremental search either with the line
found, or with the original line (respectively).
M-. or ESC then . : Both of these insert the final argument to the
last command at the cursor point. This is useful when moving files around and
editing them.
M-C-y : Insert the first argument to the previous command at the
cursor point. If you want the nth argument, hit M-n beforehand. So
M-2 M-C-y would give you the 2nd argument to the previous command. (A
lot of keys to remember, but it’s useful once in a while.)

Recent Tips
» LDAP Master Server
» Perltidy
» IPTraf

Read All Tips of the Trade

C-w and M-backspace : Both delete the word behind the cursor. C-w
uses whitespace as a boundary, whereas M-backspace uses non-alphanumeric
characters. So if you have file.txt and hit C-w, you’ll delete
the lot, whereas M-backspace would leave you with file.. This
has very obvious uses. (It also works with underscores.)

I learned some new shortcuts while researching this, so hopefully you learned
something useful, too!

Ed Note: A quick note about the Perltidy tip from a fortnight ago. Thanks to
Randal L. Schwartz for pointing out that it’s a good idea to set up tests for your code, to check that it does the same thing after Perltidy is
finished as it did before. As he discusses here, ultimately the only thing that can interpret Perl code entirely reliably is the Perl interpreter itself. So be aware that there are circumstances in which Perltidy (and similar programs) can break code!

This article was first published on ServerWatch.com.