> Not being 100% sure which command this will correct to is dangerous.

And yet the concept of the invocation `fuck --dry-run` is surely unappealing. :-)

I don't often laugh at HN comments, but when I do, I do it hard. :)

Created a pull request for a `fuck -dry` option. Did not test nor store the command so when it is ran again it is recalled, but the base is there for it to be fully implemented.

--bareback?

I think a good solution to this would be to have it display the command it's going to run with a y/n prompt. It would only add one extra keystroke and make the utility a lot safer. I think I'll make a pull request or fork or something that does this this weekend if somebody hasn't already by then.

If it defaulted to yes, then running it would be,

    fuck<return><return>

which is probably good enough. (Pressing the same key twice is pretty much the same as pressing one key, but pressing two different keys is harder.)

I used to alias `rm` to `rm -i`, until I realized that I just pressed <return><y><return> without thinking.

Or syntax highlighting as found in fish, red if your command will not run, blue otherwise, params in blue. Duno I wish more shells had basic syntax highlighting for input commands.

Here's one for zsh https://github.com/zsh-users/zsh-syntax-highlighting

I'd like it more if it just expanded to the 'correct' command and required another return to actually run:

$ apt-get install foo<return> $ fuck<return> -> sudo apt-get install foo<return>

zsh does something similar for history commands, I think:

$ echo foo foo $ echo !$<return> -> $ echo foo

Yeah I agree...the appeal of CLI is to tersely do a variety of powerful commands...and the tradeoff is that you have to be exact in your syntax. The seconds saved in not having to retype something is a relatively irrelevant optimization, which isn't bad in itself except that it also introduces a significant amount of ambiguity, which can be deadly in CLI work.

Good point, maybe don't use this for steering satellites or weapon systems.