Every time someone brings this up, I think "oh right, I could do that" and then immediately forget. Especially if you can type quickly, it's easier to just "drive straight ahead" with the command you want, than add another "mental branch" to interrupt the flow. For the same reason I'll often Ctrl+C and start again instead of trying to backspace and correct.
Rather than a sense of "cool" or "useful" somehow I end up just feeling despair at how organically convoluted it is to determine what something on a command-line really does. To be fair, I've always been biased towards "only the simplest scripts should be in shell languages."
This also adds an intriguing new dimensions to reviewing/verifying shell commands as benign and correct... How long until LLMs start (ab)using the trick in little requests they want me to approve?
The cool thing about programming languages like Ruby is that they’re very conducive to one-liners. You can use them to generate bash statements that you can then pipe back to bash. `ls | ruby -nle 'puts "mv #{$_} #{$_.gsub(/_/, ".")}"' | bash` is a pattern I use all the time, for example. Easy way of generating complex bash statements without having to bother with the bash man page.
I’ve been burnt before using ! and forgetting what command I typed previously, thus invoking the wrong command line.
!! is handy for the sudo example, but beyond that, I tend to prefer pressing the up arrow to cycle through the history rather than picking the first item. Eg:
!ssh
vs
ssh[up]
It’s the same number of key strokes but less error prone
Worth noting that `ssh[up]` isn't available by default in bash nor zsh — though it wouldn't surprise me if helpers such as oh-my-zsh enables it for you. `ssh[up]` is certainly an awesome feature — though (perhaps sadly) not default behavior.
> I've been burnt before using ! and forgetting what command I typed previously
If you want to make sure you do not execute commands you did not intend to, the section linked below is a great start:
You may also look into `magic-space` which makes the expansion of event-designators happen inline, I thought about including it but the article felt long even without it.
Thanks for reading the article, I hope it was a worthwhile read even with alternate workflows elsewhere!
the "mixing of sudo"-example is using `!!`, which as explained is the immediately previous command, a little confused how that translates to the "execute command somewhere in the history" argument?
! calls are vital for your sanity if you ever do remote support
trying to write shell commands on a hypervisor console window within a remote session on a jump box is excruciatingly laggy and annoying, and that's assuming your remote session connection to the client is behaving well in the first place
I have a script that does virsh send-key of whatever I need to send. In my specific case the motivation was the mismatch between my keyboard layout and the keyboard in the VMs, so I couldn't send M-# or even C-... into the VNC console.
I'm way too paranoid to ever use "!". I want to see the command I'm sending.
sigh The usability of ! versus Ctrl+R in a shell is pretty much the same as the usability of ed versus vi, or moving files around using cp/mv versus using Midnight Commander or the like: in the first case, you have to accurately remember the past (which for many people is pretty difficult); in the second case, you don't have to, because you always have an immediate view of the state of the system and the preview of the effect you're about to incur.
And yeah, I've done editing with ed; it definitely beats "cat >file.txt" and copying parts around with head/tail and retyping the corrections manually, sure, and it works in every environment that can take line-oriented input from the user (so, literally everywhere), but that's about as much praise as I can give it.
From personal experience I rarely reach for event-designators beyond the current viewport of the terminal. Referring to a command beyond that is, as you very much correctly point out, an easy way to get behavior you don't want. However, if you are always referring to things that are near-memory or even still directly visible in your terminal buffer — the gun-to-foot ratio becomes manageable. I use many (many) of these daily without issues, but it does require some additional discipline.
Also, and this I find important to note, `!!` and `!$` sit outside of the memory argument as they always refer to the last command and last-command's last-argument respectively — as such there shouldn't be any recall related problems (unless you are context switching and come back to a shell in a state you don't remember).
A common occurrence when my posts acquire attention is that I retroactively realize that some things could have been conveyed better; I read every comment and yours is a blessing in disguise to improve future writing.
Thanks for reading the article, and thanks for indirectly making me a better writer!
---
EDIT:
by the way, for what it's worth, the below linked section describes how to effectively explicitly confirm what you would run as a safety measure if unsure:
> in the first case, you have to accurately remember the past
Right, as a matter of (relatively trivial) cybernetics between man and machine, it rests on the weaker parts of the human.
TBF, it'd make a lot more sense if every command on screen (or given the timescale perhaps teletype paper prinout) was already labeled with the necessary number.
i love the mkdir example, so i’m going to exercise that muscle and see where it goes
and yeah ^r works, though i often type a few chars and ^p till i get the match. history-search-backward in your inputrc, iirc
edit: on a computer now :) my `if emacs` block, allowing arrows or ^n/^p to run through history. so for e.g., type "tar" and now as you shift through history with :binding:, it only shows history that began with "tar"
Everyone need be aware, bash uses emac extensions by default. As I refuse to use emacs, I therefore refuse to use these extensions in bash!
In as most sensible people use vi, don't taint yourself by touching this foul and evil emacs magic. Being known as an emacs user could cost you a job, shorten your career, or even cause
rifts with family and friends.
Instead my friends, if you must use such bash shenanigans, switch it to vi extensions. You'll feel better about yourself, stand taller, and be a better human being as a result.
Well, Emacs shenanigans are why I use Bash. Also, I last had a day job five years ago, I don't have anything that looks like a career, and well you're right about some of the family and friends.
If you really want to be lazy, use a terminal file manager (I prefer lf[0]) it helps avoiding the cd && ls dance. That way, your history only contains commands you actually would want to rerun.
Not knowing what command you are doing before you submit it is poor design. There are alternative ways to access old commands where you can see the actual command you are about to run before you submit it. The physical teletype era is over.
Every time someone brings this up, I think "oh right, I could do that" and then immediately forget. Especially if you can type quickly, it's easier to just "drive straight ahead" with the command you want, than add another "mental branch" to interrupt the flow. For the same reason I'll often Ctrl+C and start again instead of trying to backspace and correct.
As an Emacs using degenerate, `M-.` is my friend. `!` is too awkward on the keyboard.
As someone who can type rather quickly, I disagree. It can take some time to internalize, but once you do, it's much faster.
Same with Ctrl-C - once I got used to navigating by word instead of by character to correct things, it became much faster than starting over.
Rather than a sense of "cool" or "useful" somehow I end up just feeling despair at how organically convoluted it is to determine what something on a command-line really does. To be fair, I've always been biased towards "only the simplest scripts should be in shell languages."
This also adds an intriguing new dimensions to reviewing/verifying shell commands as benign and correct... How long until LLMs start (ab)using the trick in little requests they want me to approve?
Maybe it's a bit like current C++ language spec:
There's enough complexity in the language spec that most people stick with a (fairly shared) subset.
Bash can be very powerful, but IMHO there's a certain point where I find it saner to accomplish the same thing via Python.
man bash. That's the secret. man bash.
The cool thing about programming languages like Ruby is that they’re very conducive to one-liners. You can use them to generate bash statements that you can then pipe back to bash. `ls | ruby -nle 'puts "mv #{$_} #{$_.gsub(/_/, ".")}"' | bash` is a pattern I use all the time, for example. Easy way of generating complex bash statements without having to bother with the bash man page.
I’ve been burnt before using ! and forgetting what command I typed previously, thus invoking the wrong command line.
!! is handy for the sudo example, but beyond that, I tend to prefer pressing the up arrow to cycle through the history rather than picking the first item. Eg:
vs It’s the same number of key strokes but less error proneWorth noting that `ssh[up]` isn't available by default in bash nor zsh — though it wouldn't surprise me if helpers such as oh-my-zsh enables it for you. `ssh[up]` is certainly an awesome feature — though (perhaps sadly) not default behavior.
> I've been burnt before using ! and forgetting what command I typed previously
If you want to make sure you do not execute commands you did not intend to, the section linked below is a great start:
- https://refp.se/articles/your-shell-and-the-lazy-exclamation...
You may also look into `magic-space` which makes the expansion of event-designators happen inline, I thought about including it but the article felt long even without it.
Thanks for reading the article, I hope it was a worthwhile read even with alternate workflows elsewhere!
Agreed. I especially cringed at the author's example of mixing that with "sudo".
the "mixing of sudo"-example is using `!!`, which as explained is the immediately previous command, a little confused how that translates to the "execute command somewhere in the history" argument?
! calls are vital for your sanity if you ever do remote support
trying to write shell commands on a hypervisor console window within a remote session on a jump box is excruciatingly laggy and annoying, and that's assuming your remote session connection to the client is behaving well in the first place
I have a script that does virsh send-key of whatever I need to send. In my specific case the motivation was the mismatch between my keyboard layout and the keyboard in the VMs, so I couldn't send M-# or even C-... into the VNC console.
I'm way too paranoid to ever use "!". I want to see the command I'm sending.
sigh The usability of ! versus Ctrl+R in a shell is pretty much the same as the usability of ed versus vi, or moving files around using cp/mv versus using Midnight Commander or the like: in the first case, you have to accurately remember the past (which for many people is pretty difficult); in the second case, you don't have to, because you always have an immediate view of the state of the system and the preview of the effect you're about to incur.
And yeah, I've done editing with ed; it definitely beats "cat >file.txt" and copying parts around with head/tail and retyping the corrections manually, sure, and it works in every environment that can take line-oriented input from the user (so, literally everywhere), but that's about as much praise as I can give it.
> you have to accurately remember the past
From personal experience I rarely reach for event-designators beyond the current viewport of the terminal. Referring to a command beyond that is, as you very much correctly point out, an easy way to get behavior you don't want. However, if you are always referring to things that are near-memory or even still directly visible in your terminal buffer — the gun-to-foot ratio becomes manageable. I use many (many) of these daily without issues, but it does require some additional discipline.
Also, and this I find important to note, `!!` and `!$` sit outside of the memory argument as they always refer to the last command and last-command's last-argument respectively — as such there shouldn't be any recall related problems (unless you are context switching and come back to a shell in a state you don't remember).
A common occurrence when my posts acquire attention is that I retroactively realize that some things could have been conveyed better; I read every comment and yours is a blessing in disguise to improve future writing.
Thanks for reading the article, and thanks for indirectly making me a better writer!
---
EDIT:
by the way, for what it's worth, the below linked section describes how to effectively explicitly confirm what you would run as a safety measure if unsure:
https://refp.se/articles/your-shell-and-the-lazy-exclamation...
> in the first case, you have to accurately remember the past
Right, as a matter of (relatively trivial) cybernetics between man and machine, it rests on the weaker parts of the human.
TBF, it'd make a lot more sense if every command on screen (or given the timescale perhaps teletype paper prinout) was already labeled with the necessary number.
You can just add something like (\\!) in your PS1 and get just that.
PS1="(\\!) \[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ "
as a full working example
i love the mkdir example, so i’m going to exercise that muscle and see where it goes
and yeah ^r works, though i often type a few chars and ^p till i get the match. history-search-backward in your inputrc, iirc
edit: on a computer now :) my `if emacs` block, allowing arrows or ^n/^p to run through history. so for e.g., type "tar" and now as you shift through history with :binding:, it only shows history that began with "tar"
That one was always worth its own function for me.
``` mkcd() { mkdir -p -- "$*" && cd -- "$*" } ```
If you find this interesting, don't wait for a random blogpost to appear by chance on HN, go read some manage today!
Everyone need be aware, bash uses emac extensions by default. As I refuse to use emacs, I therefore refuse to use these extensions in bash!
In as most sensible people use vi, don't taint yourself by touching this foul and evil emacs magic. Being known as an emacs user could cost you a job, shorten your career, or even cause rifts with family and friends.
Instead my friends, if you must use such bash shenanigans, switch it to vi extensions. You'll feel better about yourself, stand taller, and be a better human being as a result.
Be safe.
Well, Emacs shenanigans are why I use Bash. Also, I last had a day job five years ago, I don't have anything that looks like a career, and well you're right about some of the family and friends.
You are a soothsayer!
If you really want to be lazy, use a terminal file manager (I prefer lf[0]) it helps avoiding the cd && ls dance. That way, your history only contains commands you actually would want to rerun.
0: https://github.com/gokcehan/lf
> That way, your history only contains commands you actually would want to rerun.
just turn on the thing where a leading space doesn't commit to history and you can do this already.
Not knowing what command you are doing before you submit it is poor design. There are alternative ways to access old commands where you can see the actual command you are about to run before you submit it. The physical teletype era is over.
Very annoying prose.