Hacker News Reader

Comment by kbenson | Hacker News Reader

I don't use !!, or !$, because I prefer to see what command is being executed before I press enter. For the same reason, I will never use !word. But that's not a problem, because as others have noted bash makes it easy to not have to fall back to these.

Alt-. will generally add the prior last argument into the current command, and repeated presses will cycle through previous commands.

Ctrl-r will dynamically update to show you the prior command matched as you start typing afterwards, so you can confirm it's correct.

Both are essential if you want to reuse prior commands but either can't trust that you were the last person using the shell, or don't want a typo to ruin your day, and possibly many other people's day as well. That is, if you're a sysadmin using the automatic variants, I don't want you anywhere near systems I rely on, I want you far away. Perhaps working for a competitor.

View on HN

>I don't use !!, or !$, because I prefer to see what command is being executed before I press enter.

I use zsh (with oh-my-zsh) and when I type e.g. "sudo !!" and press enter, it doesn't execute the command, instead it expands the !!. Another enter will then actually execute it.

I believe it's default behavior for oh-my-zsh. At least, I don't recall manually changing this.

You are correct.

I think by default in vanilla zsh, will expand something like 'sudo !!' by hitting tab after the second bang.

This is achieved in bash by shopt -s histverify

I don't use history expansions, though, so YMMV

Same behavior on zsh with prezto.

In zsh you can type !!<tab> and it will auto-expand the line for you. I find histverify to be kind of annoying so I don't use it.

How so?

If you don't want to rely on the "histverify" option being enabled, you can get a similar effect by appending ":p" to the history reference, e.g.

    sudo !!:p

which tells bash to do the history expansion, but print the result and add it to the command line history, instead of actually running it. If the command looks correct, it's only two more keystrokes (up-arrow, enter) to run it for real.

That feels dangerous. For example, on Swedish keyboards the character ; is one key away from :

I've got 'bind Space:magic-space' in my .bashrc, which performs history expansion after you hit space, maybe that partially helps. I guess there's friction if the expanded command isn't the one you want, which the interactive methods are better at dealing with.

I use this bash feature also.

I think this not just "partially helps", I think it completely addresses the problem described by the above commenter. Perhaps s/he is not aware of this feature.

In addition to all the other methods which have been mentioned bash has a function called history-expand-line which will expand the history inline. That allows you to even keep editing it before you hit enter. By default it's bound to the terrible M-^ (Alt-^) which might explain why nobody knows about it.

history-expand-line is documented in: https://www.gnu.org/software/bash/manual/html_node/Miscellan...

Is it the same as Ctrl-Alt-e ?

Sure is, it appears to do the same thing

> I don't use !!, or !$, because I prefer to see what command is being executed before I press enter.

shopt -s histverify

histreedit is also pretty useful especially when a substitution fails.

  shopt -s histreedit

If set, and readline is being used, a user is given the opportunity to re-edit a failed history substitution.

Until you log in to a different machine where that isn't set in the .bashrc / .profile .

> I don't use !!

Not even "sudo !!" ?

You can see the command you just typed in the line above, and you just forgot to add sudo to it.

Nope. It's easier to not have to make a decision about when to use !! or not, so I just don't. Up, Ctrl-a, "sudo ", Enter.

Another way of putting it is that I'll gladly press another 2-3 keys if it prevents a class or errors and also reduces the number of special bash instructions I have to keep in memory. !! isn't even in my repertoire, but I don't feel its loss.

per your own recommendations: "sudo ", alt-. would be one less keystroke

A lot of times it is also about muscle memory. For example although I also use alt+. a lot (although not as often as ctrl+alt+.), for adding sudo my brain reverts to up, ctrl+a, sudo simply because I was doing those long before I learnt about Alt+.

Atl-. will cycle through the n-th argument, which is not the same as repeating entire last command with all arguments as up-arrow or !! do:

  $ yum install bash-completion
  Error: This command has to be run under the root user.
  $ sudo <Alt-.>
  $ sudo bash-completion

good point, so not equivalent after all

yes, but it's not equivalent, as Alt-. only repeats the last argument.

For example, say you want to run "chown root:root foo". Alt-. gets you "foo", not the entire command, and "sudo foo" isn't useful,and in some cases could do something else entirely. For example, with the command "service foo restart", you would end up with "sudo restart" (which while it doesn't execute right away, is exactly what I'm guarding against).

M-. takes the last argument by default, but it can grab other arguments by using numeric arguments (M-1, M-2, etc.) that usually has the effect of repeating the next command.

Unlike Emacs, M-1 etc. can't be typed as C-u 1 etc.

I would never get the habit of using !! with sudo. I want to read what I do, before doing root commands... (Alt-. is possible, I guess. Maybe.)

But I'm an epic coward that even looks both to the left and the right before crossing a street. :-)

In addition to never use `sudo !!`, on systems that I use, the sudo is aliased to the following shell script:

    #!/bin/bash

    echo -n "Are you SURE you dumbass? [N/y] " >/dev/stderr
    read -n 1
    if [ "$REPLY" = "y" ]; then
      echo >/dev/stderr
      exec /usr/bin/sudo "$@"
    else
      exec echo -e "\n:-)" >/dev/stderr
    fi

That way even if I already typed my password, I systematically get asked if I'm sure I want to execute the command.

control-p, control-a, 'sudo ' return.

I think I'm pretty proficient as a basher, but I also never use the bang, nor do I use the 'history' bit. Didn't know about alt-. tho, that's handy.

I could toss 'control-k' for 'delete to end of line' that hasn't been mentioned. And of course control-P/N for previous/next commands (or arrows obviously).

Don't forget about C-e for end of line and C-d for delete character forward. C-f and C-b make more sense to learn if you have regularly use their whole word variants Meta-f and Metals (alt f/b). Congrats, you know the emacs movement keys.

With zsh, you can tab-expand history… expansion. (Despite this, I also still prefer up-arrow and ^R, since it’s usually faster to ^A and Alt-B/F than to figure out the right way to reference history.)

> I don't use !!, or !$

Neither do I, intentionally at least.

This week I encountered a very bizarre problem when running GHCi (a Haskell REPL), invoked from bash in an Emacs "shell" buffer.

In Haskell, "!!" is a function for getting an element from a list, e.g.

    > let myList = ["a", "b", "c"]
    > (myList !! 1, myList !! 2)

This would normally return the pair ("b", "c"), which GHCi prints to the screen. However, for some reason it was performing bash-like subtitution, giving me (on subsequent retries):

    parse error on input 'let'

    (myList (myList !! 1, myList !! 2) 1, myList (myList !! 1, myList !! 2) 2)

    (myList (myList (myList !! 1, myList !! 2) 1, myList (myList !! 1, myList !! 2) 2) 1, myList (myList (myList !! 1, myList !! 2) 1, myList (myList !! 1, myList !! 2) 2) 2)

and so on exponentially!

Enacs can be set to handle history substitution itself in various ways (the idea being that it can record an accurate history even when your shell can't). There's an option to configure if and when it does this, which you may want to set to never.

The !! is the reason I don't do git commit -m anymore. git commit -m "Stupid!!" gets turned into git commit -m "Stupidgit add file.c"

You can avoid that by using single quotes

> I prefer to see what command is being executed before I press enter

On a similar note, I always get nervous when using "rm -rf", since the path is written in big-endian order, so an accidental nudge halfway through typing can cause something like

    rm -rf ~/Pictures/Scans/NeedConverting/*

To become

    rm -rf ~

One simple way to avoid something catastrophic:

rm -rfi

lets you get an interactive mode so you can confirm what's happening before it gets erased.

Interesting - I use these so routinely it's unconscious, never had a problem. Though I suppose if I'm doing something remotely risky I'll not use them - though I'm not aware of doing that.

The class of shortcuts I love is:

[command] !:1-$

which copies the arguments to the previous command to this one. Or:

!:3

which copies the fourth argument.

Once those were under my fingers my fellow architects were astounded.

!* is equivalent but shorter.

!! expands the command after you type enter first...

It expands and then immediately executes, at least in bash by default.

depends on your histverify setting for 'shopt' do a

shopt -s histverify

versus

shopt -u histverify

and then add whatever you prefer (-s probably) to your bashrc

For a personal system, that's fine. For the situation where you are a sysadmin and are jumping onto one of possibly hundreds of systems, I prefer not to rely on a behavior that is specifically made more safe (implying it is less safe as it exists by default) by active configuration. In that situation, it's much easier to just not use the less safe version in favor of the safer version if not too burdensome, and both exist.

...otoh, if you are a sysadmin managing possibly hundreds of systems, you shouldn't be 'jumping onto' any one of them at all these days ! You ought to be using fabric, chef, puppet, ansible ...etc ...Ha ha, only serious ;-)

Sure, those reduce the instances you'll need a shell on a box, but they can't eliminate them. Sometimes you just need to see what's going on on that box, run top, see why there's a few thousand messages in the mail spool ad coax them through, figure out why SQL isn't responding or keeps dying, etc, etc.

Reply on news.ycombinator.com