Live data from Hacker News

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

blog.hofstede.it

251–260 of 287 posts

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

#251
post #170

Using the terminal becomes much more cozy and comfortable after I activate vim-mode. A mistake 3 words earlier? No problem: 3bcw and I'm good to go. Want to delete the whole thing? Even easier: cc I can even use v to open the command inside a fully-fledged (neo)vim instance for more complex rework. If you use (neo)vim already, this is the best way to go as there are no new shortcuts to learn and memorize.

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…

> "delete the whole thing?"

With vi (after running "set -o vi"): kC

(k to move up back one position in history. C to "change" to the end of the line.)

This is equivalent to doing the following with "set -o emacs": pu

Regardless, use what you're comfortable with or can incrementally add to your muscle memory.

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

#252
post #87

One thing I find life-changing is to remap the up arrow so that it does not iterates through all commands, but only those starting with the characters I have already written. So e.g. I can type `tar -`, then the up arrow, and get the tar parameters that worked last time. In zsh this is configured with bindkey "^[OA" up-line-or-beginning-search # Up bindkey "^[OB" down-line-or-beginning-search # Down

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

Ctrl-r can’t replace prefix search.

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

#253

One thing I find life-changing is to remap the up arrow so that it does not iterates through all commands, but only those starting with the characters I have already written. So e.g. I can type `tar -`, then the up arrow, and get the tar parameters that worked last time. In zsh this is configured with bindkey "^[OA" up-line-or-beginning-search # Up bindkey "^[OB" down-line-or-beginning-search # Down

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

```

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

#255
post #87

Earlier quoted context omitted.

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

Atuin[1] feels like the best of both worlds to me. [1] https://github.com/atuinsh/atuin

Atuin looks pretty nice — I might give it a try.

I went down the “fully automatic history” path before, but it mostly turned into noise for me.

Keeping a tiny cheatsheet of things I had to look up twice ended up working better.

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

#256
post #120

The utility of $_ is often voided by tab-completion in the subsequent command, at least in bash. You won't know what it contains, which makes it dangerous, unless you first check it in a way that also carries it forwards: printf %s\\n "$_"

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.

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

#257

I'd advise against using sudo !! though since it adds the command to history and then it's very easy to accidentally trigger, running some undesired command as root without any prior confirmation. IMO pressing up, Ctrl-A and typing "sudo " isn't much longer but saves you from running unknown commands as root by accident

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

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

#258
post #221

On scripts that might handle filenames with spaces, I include: IFS=' '' ' Hint: the spaces between the first two apostrophes are actually one . This does not affect the already written script (you don't need to press Tab instead of space to separate commands and arguments in the script itself), but by making and be the “internal field separators” will allow globbing with less quoting worries while still allowing for…

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 .

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

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

#259

Earlier quoted context omitted.

> Yeah, pressing Ctrl-W accidentially is a pain sometimes ... but Ctrl-Shift-T in Firefox is a godsend. Fun fact: despite having absolutely no menu entry for it, and I believe not even a command available with Ctrl+Shift+P, Vscode supports Ctrl+Shift+T to re-open a closed tab. Discovered out of pure muscle memory.

It's a normal command called "View: Reopen Closed Editor".

You'd think that meant "window" since they consistently call the windows editors, but I guess not

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

#260

One thing I find life-changing is to remap the up arrow so that it does not iterates through all commands, but only those starting with the characters I have already written. So e.g. I can type `tar -`, then the up arrow, and get the tar parameters that worked last time. In zsh this is configured with bindkey "^[OA" up-line-or-beginning-search # Up bindkey "^[OB" down-line-or-beginning-search # Down

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.

Or put && between them - I had "compile;run" and when compile failed, it still ran (but the old build). Took me a while to figure out. && ensures the first command succeeds. Anyway, so worth it to combine commands into one line for easy re-run.
Post reply on HN