Shell Tricks That Make Life Easier (and Save Your Sanity) (blog.hofstede.it)

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."

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.

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)

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`.

There is no value gained if you never learn.

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.

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

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

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.

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 :)

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?

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 "$@"; }

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.

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

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