Shell Tricks That Make Life Easier (and Save Your Sanity)

> life-changing

For further life-changing experience... add aliases to .bash_aliases

    alias gph='history | grep --colour -i '
    alias gpc='grep --colour -Hin '
    #if gnu time is installed
    alias timef='/usr/bin/time -f "tm %E , cpu %P , mem %M" '

Once you start using CTRL+r, you may find that you never reach for up arrow again.

Did this many years ago (but with bash) -- life changing is an apt way of saying it.

This can also be achieved with `.inputrc`:

    "\e[A": history-search-backward
    "\e[B": history-search-forward

That's a nice one.

One thing I do is configure my keyboard so that "modifier+{ijkl}" mimicks the inverted T arrows key cluster. So there's never a need for me to reach for the arrow keys. And {ijk} makes more sense than vi's {hjkl} and is faster/more logical/less key fingers travel. The nice thing is: as I do this at the keyboard level, this works in every single map. "modifier" in my case is "an easily reachable key in a natural hand position on which my left thumb is always resting" but YMMV.

I set that up years ago and it works in every app: it's gorgeous. Heck, I'm using it while editing this very message for example.

And of course it composes with SHIFT too: it's basically arrow keys, except at the fingers' natural positions.

Heh. I've done this since forever, but I use PgUp and PgDn so I can retain the original meaning of the up arrow key.

This is the default `fish` shell behavior. Type anything, up/down keys to iterate through full commands that containing the term; alt + up/down to iterate through args containing the term.

I agree it's a game changer! For bash to do the same I put this in my .inputrc:

    ## arrow up
    "\e[A":history-search-backward
    ## arrow down
    "\e[B":history-search-forward

I do something similar. I leave up and down arrows alone, but have ctrl+p and ctrl+n behave as you describe.

Atuin is better than anything I’ve used in a shell.

I'd try this, but I often find that I want to repeat a cycle of two or more commands. Yes, I probably should edit and put them on one line with semicolons (or even make a function), but.

Very nice! Here's the full code for those that had, like me, a more minimalistic .zshrc:

```

autoload -U up-line-or-beginning-search

autoload -U down-line-or-beginning-search

zle -N up-line-or-beginning-search

zle -N down-line-or-beginning-search

bindkey "^[[A" up-line-or-beginning-search

bindkey "^[[OA" up-line-or-beginning-search

bindkey "^[[B" down-line-or-beginning-search

bindkey "^[[OB" down-line-or-beginning-search

```

Oh wow I didn't know about this, thank you. The underlying feature is called "readline vi-mode" for folks who want to search more about it.

I've been a (n)vim user for 20+ years now, but I hate vi-mode in the shell. However if I feel that I need to do a complex command, I just do ctrl-x+e to open up in neovim (with EDITOR=nvim set). I find it a good middle ground.

   <esc>3bcw

What is your keyboard layout? This looks like a crime against humanity on a regular qwerty kb.

This reminds me of an excerpt from an old Emacs manual:

    . . . if you forget which commands deal with windows, just type @b[ESC-?]@t[window]@b[ESC].

This weird command is presented with such a benevolent innocence as if it's the simplest thing in the world.

I think the better advice for command-line editing would be to set up the mouse.

> <esc>cc

Doing control+o in insert mode temporarily places you into normal mode so that you can execute one normal-mode command, and then go back to insert mode again--no need to hit 'i' again.

So, instead of '<esc>cc', '<c-o>S'.

The <esc>v has been such a lifesaver at times when having to execute/modify super complex commands!

I've been a vim/nvim casual user for the past year or two, and I still feel as if I'm slightly less proficient in it for the amount of time that I put into it.

I really need to get around to playing with it more. I just hope that especially now with genAI that it's not too late for learning it further.

I use vim a lot but not on the shell

A mistake 3 words earlier?

meta-bbbd (not as elegant, I admit)

delete the whole thing?

ctrl-ak (this is even quicker than vim, especially if capslock is mapped to ctrl)

the control-based emacs movements work system-wide on macos btw. I am using ctrl-p and ctrl-n to go up and down lines, ctrl-a and ctrl-e to go to beginning and end of lines while writing this comment in by browser (which has vimium extension)

Sometimes I wish vim just had full emacs bindings while in insert mode. But I don't like to mess with defaults too much.

I keep thinking I should give vim readline a try though, so maybe today. Thanks for the comment.

I've never understood why emacs mode became the default. "set -o vi" is the _first_ command I type in a new shell.

i went even further and use neovim as my multiplexer

Eh, it's not that different from the default readline commands

A mistake 3 words earlier? No problem: <esc>3 Alt-b Alt-d

Want to delete the whole thing? Even easier: Ctrl-U

I can even use Ctrl-X Ctrl-e to open the command inside a fully-fledged EDITOR instance for more complex rework.

Ctrl-Shift-T usually brings that tab right back at least

In my terminal it's the exact opposite – Alt-Backspace deletes to the previous space, whereas Ctrl-W deletes to the last non-alphanumeric (such as /). I'm using fish shell in an Alacritty terminal.

Yeah, pressing Ctrl-W accidentially is a pain sometimes ... but Ctrl-Shift-T in Firefox is a godsend.

> Be careful working CTRL + W into muscle memory though, I've lost count of how many browser tabs I've closed by accident...

This hurts.

Also, for the shell, if you do C+w, you can "paste" it back using C+y. Assuming you have not removed that configuration.

Set $WORDCHARS accordingly. In your case, remove / from $WORDCHARS.

https://unix.stackexchange.com/a/726014

I've installed "More Better Ctrl-W" for Chromium, and mapped Ctrl-W to do nothing, and Ctrl-D to close the current tab

...which is why I recently went to about:keyboard and removed that hotkey. I love that page.

That, and Ctrl-N. No more forest of blank browser windows when using a terminal emulator in a web page!

(Firefox only)

Depends on the shell - bash on my Ubuntu deletes entire '/var/log/nginx/', while after switching to sh it deletes only nginx

'man readline' contains all the useful key combinations.

> Be careful working CTRL + W into muscle memory though, I've lost count of how many browser tabs I've closed by accident...

You're telling me!!!

(I use vim daily, with multiple splits in a single instance.)

Firefox v147 finally added the ability to redefine keyboard shortcuts, including ^w: https://news.ycombinator.com/item?id=46952095

1. Load about:keyboard

2. Find "Close tab" and click "Clear" or "Change".

> Be careful working CTRL + W into muscle memory though, I've lost count of how many browser tabs I've closed by accident...

I still maintain this is why macOS is the best OS for terminal work -- all the common keybindings for GUI tools use a different modifier key, so e.g. ⌘C and ⌘W work the same in your terminal as they do in your browser.

(Lots of the readline/emacs-style editing keybindings work everywhere in macos as well -- ^A, ^E, ^K, ^Y, but not ^U for some reason)

Yes! That one's going in my $PATH. Such a useful use of cat!

A similar trick:

    #!/bin/sh
    $*

that's my `~/bin/noglob` file, so when I call a zsh script from bash that uses `noglob`, it doesn't blow up.

What does it provide over

mycmd1 #| mycmd2

Wow I hate* that. I use bracket comments. They're cool cause they are bracket comments, so I use it in scripts to document pipelines. They are annoying cause they are bracket comments, in an interactive shell I have to type more and in TWO places. It's fun to reason-out how it works ;)

  $ echo foo | tr fo FO | sed 's/FOO/BAR/'
  BAR
  $ echo foo | ${IFS# tr fo FO | } sed 's/FOO/BAR/'
  foo

It's nice to have a way to both /* ... */ and // ... in shell scripts though:

  foo \
  | bar ${IFS Do the bar. Do it. } \
  | baz

* in the best possible way, like it's awful - I hate I didn't think of that

I think the script would be named as `#` so that it can be called via `\# mycmd` instead of `\\# mycmd`.

Fwiw, in Bash, alt-shift-3 will prepend the current command with # and start a new command.

In zsh you can bind "push-line-or-edit". In bash and all readline programs, you can approximate it with C-u followed by C-y (i.e. cut and paste). My history is still full of '#' and ':' (csh trauma) prefixed command-lines like you described though ...

You missed an easier alternative that was in the article: ctrl-u saves and clears the current line, then you can input new commands, then use ctrl-y to yank the saved command.

With zsh, I prefer to use alt-q which does this automatically (store the current line, display a new prompt, then, after the new command is sent, restore the stored line). It can also stack the paused commands, e.g.:

$ cp foo/bar dest/ <alt-q>

$ wcurl -o foo/bar "$URL" <alt-q>

$ mkdir foo <enter> <enter> <enter>

Ctrl+q in zsh is much better, I don't remember if bash has it.

You write a command, you remember that you need to do something else first, press ctrl+q/the lines gets cleared, write a different command and after you press enter to run it the old command appears again :)

Speaking of readline, I recently found out PowerShell has a readline mode (https://learn.microsoft.com/en-us/powershell/module/psreadli...) and it works great.

As someone who works mostly in WSL and has to use PS occasionally, it really reduces the overhead of the context switch.

Readline is close enough to being part of bash that it’s not really inaccurate to call these all shell features imo.

Not just the heading is LLM-flavoured. So is the writing, e.g. "The shell is a toolbox, not an obstacle course."

Or use atuin[1]

[1]: https://atuin.sh/

HISTCONTROL=erasedups can also help keeping more obscure commands in your history, at the expense of context around commands.

Also a good thing to remember if you are ever dealing with credentials:

  $  APIKEY=asdfdfds
  $ curl -H "x-api-key: $APIKEY" https://example.com

That's very cool!

To take advantage of the "leading space" one, I have this, to mark some commands that I never want to record:

       unhist () {
         alias $1=" $1"
       }
       unhist unhist
       unhist fzf
       unhist rghist     #custom command that greps .zhistory,...

Make sure to add fzf + shell integration for maximum Ctrl+r goodness.

The '-' shortcut is weird. In 'git commit -F -', the '-' is actually /dev/stdin.

I have a bash key binding, Ctrl+Y, that prepends sudo to the current command and submits it. I also don't use sudo-rs. No one has died yet.

Decades ago, i used a small dns host. I wanted to switch a personal site and they just couldn't get the final step of the transfer to work. A ton of "try now" emails spanning several weeks.

Then one day, I was trying to setup MySQL on a personal Linux machine, and it wouldn't let me use my "standard password" for the admin account. I knew I could just use a different one, but I really wanted to know what the problem was. Took a long time, and I don't remember how I figured it out, but I eventually tracked it to the password ending with '!!'.

It took a while to put it together, and I never confirmed with the dns host support it's what fixed the issue but, I changed my password there, tried the transfer again, and it worked without any help from support. I suspect my plaintext password played some part in a script used in the transfer process, and was outputting the previous command in place of the !! I wish I had asked them if that was it, but if it was, they would have to admit to having my plain text password, or lie about it.

Prepend your command with a space and now your command is not saved in the history.

i never found !! useful at all when i can just use up arrow to get the entry i want. it becomes more interesting when you can recall older commands, but then too i prefer search because i want to verify what command i am going to run.

and i only use sudo to open a root shell. never to run anything directly. i don't want normal and root commands mixed in the same history.

i could keep sudo commands out of the history, but then i don't have any history for stuff done as root.

with tmux i can switch terminals easily, so i am also not tempted to run things as root that i shouldn't despite having a root shell open.

in zsh pressing esc twice appends sudo to the last command

Pressing up, Ctrl-A and typing "sudo " adds the command to history, too. What's the difference?

It all depends on your perspective.

Are you yanking into your kill ring or yanking out of your kill ring? I had trouble with yanking and killing until I realized the complement to yanking, killing, only makes sense in the into-the-kill-ring" direction, so yanking must be out of the kill ring.

When I use vim, which I don't think has a kill ring but registers, I think I am yanking into a register and then pasting from a register later.

So, just ask yourself this: "are you using a kill ring or register to store your text?" and the answer becomes clear.

That is because the terminology (and the keybindings) come from the Emacs tradition, not vim. Most shells come with “vim mode” as well, but at least in my experience, the dual mode editing paradigm of does not feel like a good fit for the shell.

Even without tab completion, the variable can hold unexpected values due to user error (you don't see the command as a whole), multiple shell windows, or forgotten context.

Relying on it even in limited scenarios can train an invisible habit that would backfire at the least expected moment.

Any assistance intended for immediate action should itself be immediate, not indirect.

you should look into autojump which has `jc` (jump child), or other similar flavours of "smart cd" (z, fzf, etc)

I can recommend powerlevel10k with instant prompt enabled.

https://github.com/romkatv/powerlevel10k

good call

if you care about perf, fnm is better/faster/cleaner than nvm. (also, mise is able to manage "all the things", not just node)

IME omzsh slowness usu relates to overloading it w plugins, which I've never found a need for...

Agreed. I lazy-load NVM to get around that:

  lazy_nvm() {
    unset -f nvm node npm npx
    [ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"
  }
  nvm()  { lazy_nvm; nvm "$@"; }
  node() { lazy_nvm; node "$@"; }
  npm()  { lazy_nvm; npm "$@"; }
  npx()  { lazy_nvm; npx "$@"; }

> # f2 is ^[OQ; to double check, run `xargs` and then press f2

I remember using `cat -v` before learning that `xargs` exists… or maybe before `xargs` actually existed on systems I used :)

Yes, those are shortcuts used in the GNU readline library, which many programs use whenever they need to read lines of text interactively from their operators. Notable examples are (most) shells, (most) interpreters, and tools like ftp, fzf, etc.

Notably, these keybindings are it's default map, which comes from the GNU's project editor Emacs. But, there is also the POSIX-compliant, but not-default, editing mode based on Bill Joy's visual editor (vi).

I can't reproduce the glob expansion problem.

    % echo test >'/tmp/hello world'
    % cat /tmp/hello*
    test

This is bash 5.3.9.

Still, I couldn't agree more on limiting IFS. Personally, I set it only to <LF>.

In my scripts, I rely on the $(ls) idiom heavily. People I've talked to consider this an anti-pattern and suggest relying on -0, -z, --zero, --null, and -print0 flags instead. I don't deny that it's better than nothing when correctness is the goal, but I’d counter that shell is more about using a familiar interface (text representation) to solve new tasks, not about writing correct code (that’s the domain of other languages). An uncritical pursuit of correctness often results in convoluted code.

(I know that $(ls) is a subject to various expansions. I solve this problem by using a shell that doesn't do that [1].)

Another consideration is that /bin/ls and /bin/find are not the only sources of filenames. Sometimes the source is third-party or has to be user-friendly (and thus separated by traditional newlines).

Some typographical issues just can't be solved by a pursuit of mechanistic correctness. For another example, the \.txt$ idiom wouldn't work if spaces are allowed at the end of filenames. Those problems are not even shell-specific.

Those are just a few of my personal notes. Fortunately, there's a more systematic and comprehensive study of this issue [2].

[1]: https://9p.io/sys/doc/rc.html

[2]: https://dwheeler.com/essays/fixing-unix-linux-filenames.html

Wait... Most of my shell scripts have zero unused variables: I prefer to comment them if I may need them later on.

Why do you disable SC2034?

I don't think not having unused variables prevent me from doing things in my scripts!?

I understand if it's a preference but SC2034 is basically one of my biggest timesavers: in my case unused variables are typically a bug. Except, maybe, ANSI coloring variables at the top of the script.

I'd suggest `pwd -P` to resolve symlinks too. (if you use DIR to call/source neighbouring scripts).

If you're using `set -e` you almost always want a trap on ERR to print where you suddenly exited from your program. Otherwise there's no way to tell.

Also worth mentioning, but not including permanently, is `set -x` which will print every command to stderr with a `+ ` prefix before running it.

For `DIR` I usually pick a name less likely to conflict with one randomly selected in my script, like `SCRIPT_DIR`.

You also need to think about symlinks and how you want to handle them. Your current `DIR` resolution gives you the directory name without any symlinks resolved. If you're possibly a script that got symlinked to by someone, this may not be the directory of your actual script anymore, but the directory containing the symlink. As long as you want that it's fine, but a lot of the time you want the script to see it's resolved folder so it can call scripts in the real folder with it instead

Built in functionality that may offer something similar:

https://linuxhandbook.com/cdpath/

I just type "z p" in that case and that's enough to get me there.

For me I find I never have any reason to jump between directories based on frecency. Like ever. If I'm jumping between a few directories they're almost always named very similarly and that causes problems with the frecency ordering, especially when they're deep paths that get truncated.

If I really happen to be jumping back and forth a lot, I use `pushd ...`, and then I can reference my other directory with `~1/` and toggle between the two with a bare `pushd`.

post-it note until you dont need it anymore

I hate to be the AI guy, but a coach that lived in my terminal and corrected me when I do it the slow way would actually help.

I find spaced repetition Anki flash cards surpisingly effective for this kind of thing.

You’d think remembering tonnes of shortcuts and commands and flags would be alot of effort but it’s surprisingly low effort when using cloze deletions and phrased like:

- “… is to delete the last word” - “Ctrl w is to …”

If you’re not familiar with spaced repetition it’s worth checking out, especially if you have a holey memory like mine.

https://ncase.me/remember/

If you aren't aware already, you can put 'setxkbmap -option ctrl:swapcaps' in one of your startup config files, like .bashrc or somesuch. That flips left CTRL and CAPS LOCK.

omg >$ CTRL-R<specialthing>

I could kiss you.. this alone is amazing!

I don’t keep history. Any commands I think will be useful, I save it in a script.

I once saw this pattern referred to as a bashtag, which I think was an excellent name (no matter if you actually run bash as your shell or not).

One of the peer comments alludes to this and mentions that it's bash only. Doesn't work in zsh by default apparently.

That's vaccously true as you said isn't it? I write fish on my shell and then I can save it as a fish script. Worth noting that bash is much more portable and available by default, but if I'm going for portability I go straight to /bin/sh

Vi mode is also available in Claude code and gemini-cli to give some recent examples, and a bunch of other places you might not expect it, as well the more obvious places where code is written.

Once you get used to it, it is painful to go back.

And if you set `set editing-mode vi` in ~/.inputrc (readline configuration) you'll have it in even more places.

Make a better system, and we'll consider using it.

A Terminal + Bash/ZSH is soooo sticky because they are VERY good at what they do once you learn the basics and quirks. And now with LLMs, CLIs are even better because LLMs talk in text and CLIs talk in text.

Microsoft tried with PowerShell to design a better system; it "technically" is better, but not "better enough" to justify the cost of switching (on Linux). The same is true of nushell; it is "better", but not better enough to justify switching for most people.

I believe we're at "peak input method" until someone invents Brain<->Computer interfaces.

We did! Nushell and Powershell are both so much better than bash that it's not even funny. There's zero reason to use a bash derivative in this day and age, they only persist through inertia + a minority of masochists actually like bash.

You can install whatever shell you want on your system, and there are tons of better alternatives out there. Where it's actually sticky is in the lowest-common-denominator cases, when you need to throw together a quick series of commands that need to be run on a semi-arbitrary system. In that case there are VERY few options because you have to use whatever is already on the system. Sometimes you're lucky enough you can safely assume bash is present, but in many cases you have to assume only sh. Unfortunately both are a difficult/footgun enough language that it greatly helps to start out using it daily to get familiar, and that's where most people end up peaking. Additionally you may need to manually jump into that semi-arbitrary system and do things manually. You're limited by the minimal tools already there, so you better be familiar enough with them already. This is the very reason I've learned some basic Vi commands as well, even though I would never even consider using it otherwise.

In my experience Power shell is actually a terrible replacement because you have to learn not only every command, but the structured return and available input formats of every command in order to do anything. The design of almost all shells is specifically to avoid that and reduce to a common universal input/output format. Powershell could certainly be useful as an intermediate choice between a full blown language and shell scripting though, if you needed more power but not so much to make it worth the load of a real language, but would also require it to be ubiquitous already (which it's not).

What alternative would you suggest?

You can use `set vi-ins-mode-string` and `set vi-cmd-mode-string` in .inputrc to get indicators in readline, and you can add them to your prompt with a bit more work: https://superuser.com/questions/1466222/move-vi-mode-string-...

I struggle with this all the time. It's easy to start with some shell commands, and nothing beats the direct terminal running nature of a shell script. But at some point you get to where you need to do things shell isn't good at, and the cost of maintaining that part can put weight the ease of direct terminal access. Especially if you then throw in the need to make your solution runnable on a lot of systems, you now have a problem with compatibility and possibly environment setup. On top of that, if you're really experienced and good with shell, the bar for "this is difficult" in shell gets further and further away, even if it's hard for someone else to maintain.

I've been investigating alternative options with bring-your-own-tool for this situation at $JOB, mostly making use of shebangs to trigger environment setup from self-contained utilities packaged with the scripts, and there are some promising options. Things like `uv` to setup a self-contained one-off python venv automatically so you can write in Python instead, possibly with one of the packages that helps with the many subcommands footguns, or to write `xonsh` if you want something more shell script leaning but with Python power. Or you can alternatively go with a language agnostic solution and use shebang triggered `nix-portable` to construct a whole isolated custom environment automatically from a flake.nix and run whatever tools and mishmash of languages you want.

or - as an alternative to <esc> + ".":

for the last argument

* <alt> + "."

if you want the -<n>th argument:

* <alt> + "_" # n times :=)

* <alt> + "."

cheers a..z

ctrl-z pauses the process, it doesn't terminate. I think of z as in zombie as you can then run fg to bring it back from paused state or as you suggested kill in it for good

All of the keyboard-driven terminal signals can be intercepted; catching INT (^C) for cleanup is just more common than the others. Only KILL and STOP cannot be caught.

^Z sends TSTP (not STOP, though they have the same default behavior) to suspend; some programs catch this to do terminal state cleanup before re-raising it to accept the suspension. Catching it to do full backout doesn't make as much sense because the program anticipates being resumed.

^\ sends QUIT, which normally causes a core dump and is rarely caught. If you have core dumps disabled (via ulimit -c 0 or other system configuration) then you can often use it as a harder version of ^C; this is how I would tend to get out of ‘sl’ in places where I found it unwantedly installed.

For the most simple case of a single job, I use the job number (`[1]` in the example) with %-notation for the background jobs in kill (which is typically a shell builtin):

    $ cat
    ^Z[1] + Stopped                    cat
    $ kill %1

it did not work for me in putty, so i added ctrl-x + ctrl-u too:

  bind '"\C-x\C-u": undo'
  bind '"\C-_": undo'

I knew many of these tricks, but learned many new tricks I didn't know and looks very useful (like you can do Ctrl-Y after an Ctrl-U, the 'reset' or 'disown' thing).

Regarding experience, I'm also struck by how many "experienced" engineers are just clueless with the keyboard.

I think the keybinding suggestions are really nice. My shell is configured by default such that Alt+Left and Alt+Right move by a word, but having things that work out of the box, basically always, is really useful whenever I need to do things inside a docker container

I try to keep a list somewhere, but I only pick one or two that are likely to be most useful and try to remember them until they're such a normal part of my workflow I don't have to think much about them anymore. Then I go back and pick a couple new ones to add.

The hard part is when you've reached the point where all your common use cases are covered and you're left with only uncommon cases. Then it's extra hard to remember you had a trick for dealing with the uncommon case.

AFAIK that setting is opt-in, at least in Bash.

What is it like to be this proud of not learning the tools you use? Do you really think several paragraphs to an agent that may or may not be correct is the "easy" way compared to just checking the manual for the flag you want?

I will never understand people like you.

I'm confused; how is writing a shell command (using shortcuts like those in the article!) "wasting time", but describing what you want to an LLM, having it make a plan, reading the plan, editing it, and running it is somehow not a waste of time?

You also mention there being "little value", when your proposed approach costs literal money in form of API/token usage (when using hosted models).

> Now I've moved to coding in Haskell

You might like https://hackage.haskell.org/package/turtle or http://nellardo.com/lang/haskell/hash/

There is no value gained if you never learn.