> For the same reason I'll often Ctrl+C and start again instead of trying to backspace and correct.

Try ctrl-x ctrl-e to edit the command in your choice of editor ($EDITOR).

Editing commands is not hard with a few keys. At least learn alt-b and alt-f to go a word back or forward. Often ctrl-left and ctrl-right will do the same thing easier (depends on your terminal). Ctrl-w deletes back to the previous space, alt-backspace and alt-d delete the previous and next word respectively. There are many more keys in the manual, but those cover most things.

"sudo !!" is quite firmly burnt into my muscle memory, but the whole rest of the time when I type an exclamation mark I mean it literally, and I get annoyed when it turns into a syntax error of some variety.

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.

Your questions would be a great addition to the FAQ, thank you!

--

> When I enter `sudo !!` will it be stored unchanged in the shell history, or stored after interpolation of `!!`?

event-designators themselves do not end up in history, it will be the expanded contents:

    $ echo "hello world"
    hello world
    $ echo !$:s/world/idoubtit/
    echo "hello idoubtit"
    hello idoubtit
    $ history
        1  echo "hello world"
        2  echo "hello idoubtit"
        3  history

> When I start a command line with a space, so that zsh does not put it in the shell history, will !… also ignore that line?

leading space to ignore adding things to the history is not default behavior, but event designators will still be able to capture their contents. Notice how "echo 321" is _not_ part of the history, but our usage of !$ is:

    % setopt HIST_IGNORE_SPACE
    % echo "abc"
    abc
    %  echo "321"
    321
    % echo last-argument-was !$
    echo last-argument-was "321"
    last-argument-was 321
    % history
    22092  setopt HIST_IGNORE_SPACE
    22093  echo "abc"
    22094  echo last-argument-was "321"

I think this is indirectly answered by the above, if not let me know and I will see if I can answer.

---

Will try to update the post within the next few hours with your additional questions — much much appreciate the feedback, and thanks for reading!

FAQ updated: https://refp.se/articles/your-shell-and-the-lazy-exclamation...

really appreciate the feedback, thanks a million!

instead of !$, I use alt+. for the same reason `up` is preferable to `!!`.

!$:h is new to me. directory name of last argument is nice. I can imagine reaching for that. paired with alt-^ to replace the magic with the actual expanded text before hitting enter

`IMO, !$ is most useful of them all (it is the one that gets replaced with the last argument of the last command).`

I've been liking Esc+. for this. It doesn't usually work in browser sessions though, have to do Ctrl+[+. which is a strange feeling 3 finger salute. For some reason I'm able to remember that one rather than !$

Edit: apparently Alt+. does the same, wow.

>!! you can do just as easily with up-arrow enter

  sudo !!

And for editing that command line... I know a lot of people who know about Ctrl-a, Ctrl-e, Ctrl-k, but still hold down the left arrow key or delete key a lot to edit things in the middle.

Those people want to use:

    Alt-f    move cursor forward one word
    Alt-b    move cursor back one word
    Alt-d    delete to the end of the next word
    Alt-Del  delete backwards to the start of the previous word

    Ctrl-_   undo

I appreciate the true snark of this :)

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.

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

Author here, thanks for reading and taking time to reply!

---

You are very much correct that `Alt-.` with modifiers can do more than what has been described, it is however important to note that the behavior of `Alt-<key>` changes heavily both between zsh and bash, but also between `vi-mode` and `emacs-mode`.

For instance, zsh will switch to `vi-mode` depending on env variables such as `$EDITOR`, making `Alt-<key>` unavailable in that regard.

---

It's also worth noting that `ctrl-alt-e` is _not_ a zsh default, though it is a fair point that it could have been added in the below linked section:

https://refp.se/articles/your-shell-and-the-lazy-exclamation...

For what it's worth, I had troubles finding a proper scope for the article contents — and with that the lines became a bit blurry in terms of what to include, and what not to include.

---

I really appreciate constructive comments like yours, and hope it together with the article can help future shell ninjas!

This article taught me about alt-. and it's probably going to become my new favorite fish shortcut: if I type a portion of a word (for example an ssh hostname), hitting alt-. searches all previous arguments and autofills the entire username+hostname at that position. Seems much more powerful than bash's implementation. (and allows you to go forward/backward with alt+arrow keys if you overshoot it)

Instead of alt-^, I set “magic-space” in `.inputrc`.

This will expand the event designator after you type space to end it. So you type “!” “$” “space” and the designated argument expands in-place.

i use `shopt -s histverify` instead of ctrl-alt-e.

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.

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:

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

    bind space:magic-space

That one was always worth its own function for me.

``` mkcd() { mkdir -p -- "$*" && cd -- "$*" } ```

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!

It’s a funny comment, but it’s also sort of true. Back in the stone ages I had to go from Solaris to sunOS to QNX to Unixware to HPUX to Linux to BSD (maybe freeBSD was in there too) and many others that I can’t remember. Oh yea, Irix, too. This is all in a 2 year period. Vi was the only editor that was on all of these machines so I (to this day) could never be bothered to learn anything else.

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

For this reason I recommend avoiding using history expansion features with any commands in history that might destructively modify file contents, such as `find ... -delete` in GNU find.

In the default Bash Emacs readline bindings, you can type Alt/Meta-^ to expand history on the current line without executing. You can also set `shopt -s histverify` to expand the history substitution on the following line after pressing enter/submitting the history substitution and it also does not execute the command.

You can add :p to print the command.