refp

really appreciate the feedback, thanks a million!

Disclaimer; author of this post, and also https://refp.se/articles/non-constant-constant-expressions and related post in that series.

What you can do with what is always hard to answer given that all roads lead to Rome, though some roads have more turns than others.

---

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!

--

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

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

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

I submitted the above link, seems HN is rewriting it automatically. :-/

> This is my body's reaction to that news.

> HR, Sleep, and Energy scores recorded by my [smartwatch]

https://refp.se/articles/your-shell-and-the-magic-colon#why-...

I am not asking anyone to put this in production, it is a tongue-in-cheek/cute way of explaining/showing what the null-command _can_ do, not what it _must_ do.

No, any distro that stopped shipping entities mentioned to use only null-command variants.. well, I'd save whatever your end goal is to a meeting with them.

Just enjoy the article for what it is — a piece of trivia.

Best Regards, Filip Roséen - refp

https://refp.se/articles/your-shell-and-the-magic-colon#why-...

I wrote my first real `.ps1` the other day for auto-installing all dependencies needed to run a `gitea`-runner on windows for windows builds; powershell - felt like the lover I never had. And the documentation in readable comments at the top that just.. generates usable docs? Damn, damn, damn.

There is a part of me that low-key wanna try that as my daily driver for a week or two. But with that said, I'm a zsh vi-mode guy - always have been, always will be.. but I'd happily take powershell on a romantic getaway every once in a while!

Fast-forward to seeing that comment climb up the ranks, posted by a person who has 270x my karma, who seemingly gets upvotes by just.. writing things? no proof? no rationale? nothing?

Yeah, feels bad. I'm super happy so many are enjoying the article, and this situation can't take too much away from that, but man.. discouraging for sure.

  zsh% echo "hello world" > data
  
  zsh% < data && echo "READABLE"   # <- will print the contents of data
  hello world
  READABLE
  
  zsh% : < data && echo "READABLE" # <- this will not
  READABLE

---

and given that we use the null-command, it _WILL_ behave different with or without subshell.. and all you need is `bash --posix` to prove it:

    % cat subshell.sh
    #!/bin/bash --posix
    ( : < missing.json ); echo AFTER    # <- will echo AFTER
    
    % ./subshell.sh
    ./subshell.sh: line 2: missing.json: No such file or directory
    AFTER
    
    % cat no-subshell.sh
    #!/bin/bash --posix
    : < missing.json; echo AFTER        # <- this will not
    
    % ./no-subshell.sh
    ./no-subshell.sh: line 2: missing.json: No such file or directory

    % : ^- apparently.. there is a difference

---

One should never trust things just because they are written, but that also applies to comments on HN. Originally when I read your message I actually thought I made a mistake, I was very close to writing an apology comment and adding a note to the blog post, but not close enough - I had to test it again.

I'm thankful for the watchful eyes and scrutiny when reading things online, that's good - keep it up, but your message is factually wrong - on so many levels.

---

It is a (contrived) example of usage where a command is required and `:` can fill in the blanks. There are certainly scenarios where negating an expression becomes harder than doing the "dumb" way, and I for one has written code where `:` can be used as a placeholder meaning "fill this in later" or equivalent.

With that said, 100% agree with you that in actual "production" code - there is always a cleaner way.

I agree with you, and for what it's worth the truncation snippet is very much tongue-in-cheek much like `( : >> output ) && echo "is writable"`.

I wasn't expecting anyone to actually use these in Prod, rather I aimed to show what can be done with a command designed to.. do nothing (crazy).

Happy you enjoyed the article, and thank you!

You are very much correct and I 100% agree with you, I have updated the first example to include a snippet where a proper env-var is used to show of the automatic diagnostic.

Thanks for your feedback, much much appreciated!

are you gonna spot the LLM bill or should I?

    Another approach might be to sit back, have a nice cup
    of zen, and just always pull all updates and then
    update your entire fleet of systems on a weekly basis,
    which, yes, I sure would like to be able to do, but
    reality keeps getting in my way.

    I'm not sure what to do here going forward.

    -Jan

But now.. are we simply supposed to use our f̶a̶v̶o̶r̶i̶t̶e̶ package manager and batch update our systems in a loop?

    while true; do apt-get update && apt-get upgrade -y; sleep 1d; done