Cool idea. For those systems where you don't have the option of adding a 3rd party tool, it's probably worth knowing some of the standard bash shortcuts. The easy to remember ones are:

  !^ - the first argument from the previous command
  !$ - the last argument from the previous command
  !* - all of the arguments from the previous command
  !! - the entire previous command

For example:

  $ apt-get install foo
  # Crap
  $ sudo !!

Let us not forget, also substitution regexs in bash...

    $ ls -l /tmp/foo
    ls: cannot access /tmp/foo: No such file or directory
    $ !:s/foo/bar
    -rw-rw-r-- 1 user user 0 Apr 17 19:12 /tmp/bar

And the shorthand:

    $ ls -l /tmp/foo
    ls: cannot access /tmp/foo: No such file or directory
    $ ^foo^bar
    -rw-rw-r-- 1 user user 0 Apr 17 19:12 /tmp/bar

And the reason for the other approach - global substitution (otherwise the caret approach is simpler)

    $ ls
    hello_world hi_there_world
    $ mv hello_world hello_everyone
    $ !!:gs/hello/hi_there
    mv hi_there_world hi_there_everyone
    $ ls
    hi_there_world hi_there_everyone

Nice. Now that we're getting all stackoverflowy in here, it would be worth mentioning two other handy tips.

Preventing typo mistakes with bash autocomplete is even better than correcting mistakes afterwards, it also makes typing so much faster. It works with commands AND it also works for files inside the current working directory.

Hint: start typing your command and then hit TAB, voilà! Note: if there are more than 1 command/file option that starts with the same chars you wrote, hit TAB twice and you will have all the options displayed in front of you, it comes in handy to remember fast instead of browsing documentation.

Command example:

$ git rem[TAB] ---> $ git remote

$ git remote a[TAB] ---> $ git remote add

File example:

$ git add i[TAB] --> $ git add index.js

Multiple options example (TAB twice):

$ git r[TAB,TAB]

(will give you the options:)

rebase relink replace revert reflog remote request-pull rm release repack reset

The result is NO TYPOS! ;)

--------------------------

It would also be worth remembering the unix convention of using $ for regular user prompt and # for super user prompt.

In other words:

$ <--- if this is your prompt you're working on a regular user session.

# <--- if this is your prompt you're working on a super user session and you don't need sudo.

Again, that is just a convention, your OS/distro could be different.

When I was typing the '#' I was thinking 'comment', not 'root shell'; in retrospect I can see how it might have been confusing, especially when my example used 'sudo'.

I was not criticizing your use of # at all. Using # to comment is perfectly fine I guess. Now that you mentioned it, it might be a bit confusing for newbies, but don't worry I don't think anyone would try to send the command 'Crap' over a super user session, although why the hell not? haha

BTW, all of those commands are from the original BSD c-shell. Bash developers knew a good thing when they saw it.

Typo correction is useful too.

^foo^bar

git brnch

^r^ra

This works on all Unix machines

*Works if properly implemented. Had to manually disable this behavior in eshell as it prevented you from running regex with two carets, e.g. '$ grep -E '^sometext[^ ]+moretext'.

You can also just run a sed style substitution in most shells, e.g. '$ !!:s/before/after/' or '$ !!:gs/x/y/', which is safer IMO.

You know... I've seen this notation on discussion forums (and probably IRC etc.) for years, and had no idea until now that it was a reference to this shell capability lol

I use $_ all the time, since it's the last argument to the previous command [after expansion]. Example would be:

atom path/to/so[tab]/fi[tab] [return] git diff $_

Complete reference: https://www.gnu.org/software/bash/manual/html_node/Variable-...

See also: http://wiki.bash-hackers.org/syntax/shellvars

You can also specify a specific argument number from the previous command with colon notation e.g. sudo dpkg -l !:2

alt-. (Alt-period) is a good shortcut to keep in mind. On first press, it inputs the last arg from the previous command. If you press alt-. again, it inputs the last arg from the previous-to-previous command. And so on.

Huh, I didn't know about that. I use Esc+Period to the same effect.

I've been using "sudo !!" (which I pronounce as sudo bangbang in my head) for a while now, mostly with vim for editing stuff in /etc. It's very nifty.

Another nifty tool is vi editing mode. You run "set -o vi", and now your shell takes vi modal editing commands. That along with Ctrl-r for reverse history search has made life in the shell so much easier. Bash has a ton of little stuff like that built in. Zsh has a few more.

Probably my biggest overall timesaver has been:

   :w !sudo tee %

If you neglected to sudo before making your changes.

I've had this in my vimrc for years:

   " Let :w!! gain sudo privileges without closing and reopening vim
   cmap w!! w !sudo tee % >/dev/null

Its much more easier to remember when you know how that actually works. Here is link explaining how that actually works:

http://stackoverflow.com/questions/2600783/how-does-the-vim-...

Yes, that vi editing mode of bash is very useful. IIRC it was there in ksh too. Some people might not know that you can use both the insert/append mode and the command mode of vi(m) in that vi editing mode of bash, to edit previously entered commands. You just switch between the two modes the same way as you do in the real vi(m), with ESC to go from insert/append mode to command mode, and i or a to go from command mode to insert/append mode.

Also, after you have entered a previous command, to edit it, or any previous command in the history, the first thing you have to do is press ESC (to go to command mode) and then k, thereby bring the last entered command into view for editing.

When editing a command, but in command mode (not insert/append mode), you can also press v to open the command in vi(m) in a temporary file, then have the full screen editor at your disposal to edit the command (useful for long scripts including for/while loops or long pipelines), and then when you save and exit (:wq or :x followed by Enter), the newly edited command gets executed by bash.

Also, this editing technique is useful not only for correcting typos in commands, but for modifying a previous correct command, to change some words in it and then re-issue it.

I also use that all the time, and pronounce it as "sudo", but with more excitement.

sudo !! is my favorite thing. I named my cat sudo bangbang.

I don't see the advantage over pressing up, C-a and typing sudo

Historically: it predates the ability to do interactive line-editing.

An issue that popped up for a user, kind of funny:

https://github.com/nvbn/thefuck/issues/1

  who@where:~$ fuck
  No fuck given
  who@where:~$ fuck
  fsck from util-linux 2.20.1
  e2fsck 1.42.9 (4-Feb-2014)
  /dev/sda6 is mounted.

  WARNING!!!  The filesystem is mounted. If you continue 
  you ***WILL*** cause ***SEVERE*** filesystem damage.

  Do you really want to continue<n>? no 
  check aborted.

If you're less adventurous, and use fish/tmux, you could try something like:

  # config.fish
  function fuck
      thefuck (history | head -n1) | tmux load-buffer -
      tmux paste-buffer -s \0
  end

This will paste the command The Fuck suggests without a return so you can audit the corrected command before running it.

Yup, is it possible to simulate the "up arrow" but fix it first before injecting it back into the input field of the terminal?

Yeah, OP here. It really almost gave me a heart attack ;)

In other words: don't go fuck yourself! ;)

Git already has a config to do this:

  help.autocorrect

  Automatically correct and execute mistyped commands after waiting for the given number of  deciseconds (0.1 sec). 

  If more than one command can be deduced from the entered text, nothing will be executed. If the value of this option is negative, the corrected command will be executed immediately.

  If the value is 0 - the command will be just shown but not executed. This is the default.

http://git-scm.com/docs/git-config

Cool, didn't know about that before.

Not being 100% sure which command this will correct to is dangerous. Also the need for this is largely negated by a shell with autosuggestions.

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

99 times out of 100, my issue is forgetting to sudo a command, so I just have 'alias fuck="sudo !!"' in my ~/.bash_profile

Check it out: https://github.com/seletskiy/dotfiles/blob/master/.zsh/alias...

Far more easier to press CTRL-T than type `fuck` every time.

Zsh's completion system handles most of those examples if enabled:

http://zsh.sourceforge.net/Guide/zshguide06.html#l162

http://zsh.sourceforge.net/Doc/Release/Shell-Grammar.html

http://zsh.sourceforge.net/Doc/Release/Expansion.html

It can actually be integrated into history expansion, used at will, configured with a custom prompt, told to ignore certain words and files that annoy you, etc. But if you try to search for "zsh correction", most posts are related to disabling it entirely.

I think it's a funny little app. I could see it being kind of useful for the author but I think I would personally have trouble using an app that I don't actually know what it's going to do 100%. I think that you could mitigate this a bit by putting the list of commands it corrects right at the top of the readme.

I think most of us have probably been at the point where we were typing something like "I hate you, you god damn computer!" into the terminal or text editor. I see this as a moderately elegant helper in those situations

Check out the only issue open: https://github.com/nvbn/thefuck/issues/1

I like it, but I have to know every command it modifies/checks, I cannot run a blackbox command and hope.

That issue has an alias you can use:

    I just added an additional alias for testing. 
    It simply outputs the command fuck would execute:

    alias tryfuck='thefuck $(fc -ln -1)'

I added info about how it works and what it can do in readme.

And yep, it can add sudo to your previous rm -rf /.

'I could see it being kind of useful for the author...'

That was my impression. It reminded me of little custom scripts or functions I've created that help with my day to day work, things I wouldn't necessarily give to someone because they were built with myself in mind. I know how they work and exactly what they do.

"In one notorious incident, Warren added a DWIM feature to the command interpreter used at Xerox PARC. One day another hacker there typed delete $ to free up some disk space. (The editor there named backup files by appending $ to the original file name, so he was trying to delete any backup files left over from old editing sessions.) It happened that there weren't any editor backup files, so DWIM helpfully reported $ not found, assuming you meant 'delete *'." See http://www.catb.org/jargon/html/D/DWIM.html and also https://en.wikipedia.org/wiki/DWIM

I wrote a similar Sudo History Invocation Tool to do this: https://github.com/christianbundy/shit

What I really want is a wrapper for sudo. Whenever I use sudo, if type the password correctly it works instantly; if I mistype the password, it delays for 2 seconds before asking again. Often it's faster to Ctrl+C UP ENTER than to wait for that annoying 2 seconds. So it would be nice if a wrapper existed to see if sudo gives access within 0.1 seconds, and if it doesn't, assume the password was wrong, kill the sudo process and launch the command again. Automate the Ctrl+C UP ENTER.

I suspect the delay in sudo is configurable: it's not there because sudo is actually doing any work checking your password, it's there to prevent attackers from trying many many combinations of passwords quickly.

If you care about that protection, then you don't want to circumvent it, but in the equally reasonable case where you don't care, then you can probably just make sudo faster.

It actually comes from PAM - man pam_faildelay

How is it offering protection? An attacker could use this scheme as well. If the server doesn't let the user through in 0.1 s, abort and retry the connection, circumventing the delay.

You can limit the amount of retries, so a delay between attempts by default seems a little silly to me.

.. ten seconds until there's outrage against the name and a campaign to have it cleaned up. (see: Karma)

Very useful though.

I've started to wonder why we've never seen a more IDE-like autocomplete in consoles. I mean, why do I have to use man pages and all sorts of reference guides to remember the parameters for find or grep or whatever, or the order of commands for whatever?

There really needs to be better communication between software and the environment it's running in.

I feel like fish gets part of the way there by grabbing stuff from the man pages and displaying descriptions in tab-complete options. But we're still a ways from the anti-Mac user interface[1]. Unless maybe you count Google's search bar.

[1]http://www.nngroup.com/articles/anti-mac-interface/

Projects like this always make me think the developer's imagination has drastically failed them with respect to the scope of negative consequences that may result from using their tool.

Projects like this always make me think the developer's imagination is great and they must at least be intelligent enough to criticise their work (with humour).

Added the `fuck --dry` option from the comments below, waiting for it to be merged.

All it does is print the command to run and prompts for [Y/n].

Issue #1 is classic.

Running 'Fuck' twice attempts to evaluate the previous 'Fuck'- and returns 'fsck' - which tries to forcefully check your mounted drive.

I wouldn't trust this app for practical use.

You can surely trust that it will 'fuck' stuff up at some point.

Got to love https://github.com/nvbn/thefuck/issues/5

I think i will continue using the Fish shell feature instead. It has this awesome feature of autocompleting your command with the bash history of yours.

It is safe because it will autocomplete a command that you wrote before.

Another cool thing with it is that, it will list the commands that you can run after entering a word. It does this by reading the man page of the command you write.

brew <Tab> will list the brew commands for you to use with its explanations.

I will not let my coworkers see me typing expletives into terminal; much less if it is a woman.

It is a nice idea, though. Will use it if it's called auto-correct or something.

I'm not sure what difference you think gender makes, unless you think women are delicate flowers that must be sheltered from bad language, but I do agree that it would be better named something more office friendly. I'd suggest 'argh', 'grr' or 'gah'.

Profanity is (deliberately) uncomfortable to people who are not part of your in-group. Women are more likely to be/feel excluded from in-groups in technology workplaces.

If I specifically don't swear around a woman colleague, while I would usually swear around all my male colleagues, isn't that exclusionary? Wouldn't treating her the same as I treat everyone else be more inclusive?

Profanity is a wonderful spice of life, it is deliberately uncomfortable to people who take things way too seriously.

Get back to me after someone you don't like or don't trust throws you some of that spice.

> Women are more likely to be/feel excluded from in-groups in technology workplaces

... because people want to treat them differently, perhaps?

I get your point, but I think the problem is with in-group behaviour. You are comfortable with swearing if you're very comfortable with the group dynamic.

But there are plenty of out-groups in technology along plenty of lines, who may privately be uncomfortable in this situation; and gender is only one of those lines.

If we pretend there is no problem with gender that needs addressing in this respect, it's not that we are excluding women: it's that we are excluding every aspect of diversity in technology.

Simply change the alias to something else:

    alias doh='$(thefuck $(fc -ln -1))'

The birth of a new metric:

alias WTFs="history | grep fuck | wc -l"

Here's an equivalent "alias" for the fish shell:

    function fuck
        eval (thefuck (history | head -n1))
    end

Thanks, added to readme.

Made an Arch AUR package. First time making VCS package. Might be terrible.

https://aur.archlinux.org/packages/thefuck-git/

I'm not quite sure I understand why this is any better than using the up arrow.

I thought the cardinal rule of sysadmins was "think before you press enter". This seems to discourage that mindset.

C-o https://www.google.com/search?q=readline+operate+and+get+nex...

it's only me to just tap "up" and edit the command?

I just keep getting "No host name on command line, aborting."

Also was asked to install "suck." Not sure why / what that is.

One of the issues on the Github reveals that at least one user ended up running "fsck" after typing "fuck" twice. :)

Mildly related: http://bropages.org/

I wonder if the name came from some version of this pithy one-liner:

To err is human, to really fuck things up requires a computer.

I was expecting to see in the examples:

  $ wrongcommand
  error
  $ fcuk
  command not found
  $ fuck

This.

Out of the box bash trick:

   export EDITOR=vim
   C-p (or Up)
   C-x C-e

Someone should fork fish and create fuckfish: a shell that fucks automatically

For those wanting something safer but similar, see the `fc` shell function.

yea, lots of us use shells with suggestive text...that doesn't make this less amusing. Now if only someone would make rules for my osx terminal, thatd be great

Super interesting. I LOLed. But I will not install it.

Also, fix command might help

$ fc

What the Exclamation mark.

I praise you for giving us the fuck!

Unix 'fc' or fix command

$ rm -rf / oops

permission denied

$ fuck

sudo rm -rf --no-preserve-root / oops

$ _

alias fuck='sudo $(history -p \!\!)'

I'm going to go out on a limb here and suggest that you rename it "The Fix." Then you could type "fixit" or just "fix".

I rather enjoy the abrasive edge of many parts of programming culture and prefer it not be dulled, even when it ends up cutting me.

There's no way I'd be comfortable using this at my sterile, overly PC corporate work place.

Then fork and rename it?

Done: https://github.com/shaungallagher/thefudge

You can name the shortcut whatever you want by modifying the alias:

   alias fuck='$(thefuck $(fc -ln -1))'

Call it thefork?

Yes, using the word "fuck" for this just strikes me as a bit immature.

If it was called the fix it never would have made it to page 1

Would make me more likely to recommend it as a serious tool to a colleague though. But then again I'm a curmudgeon.

I get the impression that it's more of a joke than a serious tool. It is actually quite funny, but I can't imagine anyone using it seriously.

Also if anyone really cares, they could just fork it and make the change.

And then update it whenever the upstream changes. And keep track of all any new references which need to be modified. And publish a package if you still want it to be installed easily. And so on.

American prudishness. There's nothing immature in swearing in and of itself.

I'm not an American, and I'm not prude. I use quite a few swearwords regularly. However this just strikes me as an immature thing to do.

> American prudishness

Sounds like you need a review of: https://news.ycombinator.com/newsguidelines.html

Or perhaps just some common decency ? If you want a tool / platform to take off, using the word 'fuck' is not the way to go.

I too read those guidelines in their entirety and there is nothing there at all about the poignant use of so-called "swear words."

Also:

http://thefuckingweather.com/

http://www.whatthefuckshouldimakefordinner.com/

etc.

Which part of the guidelines? I reread the entire thing and didn't find where it would apply.

Swear words don't break the HN guidelines. When we ask for civility we have in mind how people treat one another online. Swear words can be used to treat others badly, but they have plenty of other uses.

It's not a trivial question, though, and people aren't wrong to disagree. Cultural differences make for very different views here. In some (sub-)cultures swear words are uncivil and in others they are innocuous. There's no model that satisfies all these norms, so inevitably we have to disappoint some.

As a consequence of the above, we don't bowdlerize titles either.

> swearing

Most actual instances of the actual word "fuck" aren't even swears.

"When I first opened Tropic of Cancer and saw that it was full of unprintable words, my immediate reaction was a refusal to be impressed."

The whole thing is something of a joke, and the name is just part of that. I don't think it's meant to be taken very seriously to begin with.

You must not really be a programmer ;)

Late night, vision is starting to blur and you've typed `git push origin master` incorrectly dozens of times already...

    $ FUCK!!!111ksjdkjsd

I know a guy that does all his "printf debugging" using variations of printf("penis\n"). As a bonus, its a good incentive to remember to get rid of the printfs when you are done :)

I do that too, I think twice before typing 'touch penis' to create dummy files in my bash scripts though.

I say leave it as is, in those example you can almost hear that intonation you say it (in your head or out loud) when mistyping :)

People are not materially harmed by short strings, so no.

What if they were objects?

Fork it if you care that much.

Looks like someone already has, actually: https://github.com/shaungallagher/thefudge

But seriously, I can't some up with a single situation where using "fudge/crap" instead of fuck would matter.

Agreed. They could even sanitize it a little bit as 'wtf' or 'oops'.

There's already a "wtf" program, available in Macports and probably some other package managers. It has a database of internet acronyms, and otherwise it seems similar to commands like "apropos" and "whatis".

  ~> wtf is imnsho
  IMNSHO: in my not so humble opinion
  ~> wtf is cat
  SVK::Command::Cat(3pm)   - Output the file from depot
  cat(1)                   - concatenate and print files
  fc-cat(1)                - read font information cache files
  git-cat-file(1)          - Provide content or type and size information for repository objects
  ~> wtf is fuck
  fuck: nothing appropriate

http://cvsweb.netbsd.org/bsdweb.cgi/src/games/wtf/

WTF means the same thing. That is no less vulgar.

> WTF means the same thing. That is no less vulgar.

Vulgarity of expressions is not a function only of what the expression means, but of the acceptability of the expression itself in various social contexts. WTF is, generally, acceptable as not excessively vulgar in social contexts where expanding the last letter of the initialism into its referent would not be, but the reverse isn't true; WTF is pretty close, therefore, to strictly less vulgar.

This may not seem rational, but then the entire concept of vulgarity is irrational.

> "WTF is, generally, acceptable as not excessively vulgar in social contexts"

Which social contexts? Social contexts where people don't know what "WTF" expands to? It's not even a "minced oath".

"WTF" is less vulgar than "fuck" for roughly the same reason that "the f-word" is less vulgar than "fuck".

I don't buy it.

"The f-word" is used exclusively by people being descriptive. Nobody says "So I was f-wording my spouse..." or stubs their toe and exclaims "oh f-word!". It is used when people are reporting what other people said. That is why it is considered less offensive; it is never properly used.

It signals to the easily offended, "I want to convey this information to you, but I am deliberately mangling words so that you know I too disapprove of the terrible word that was unfortunately used by somebody else."

"WTF" isn't used that way. When people say it, they are using it, not describing somebody's usage. There is zero implication of an apology or empathy with the audience's word-phobia.

It's arguably ambiguous as to whether the oath would have been minced, if expanded. I've certainly heard people say "what the frick" or similar.

I would, because a lot of commands could be improved by a "do what I mean" option.

GNU find is smart enough to tell me that I've placed one of the flags or the find string in the wrong place, but not smart enough to correct the fucking error and do what I meant in the first place. (It knows, it just won't do it.)

"apt-get/yum install" is unusable by anyone but root. Why do I need to waste time re-keying the command? This is annoying enough that I've aliased it[1] on every machine I have access to.

I'd be willing to bet the collective man hours wasted on these worthless "you did it wrong, here's how you did it wrong, now go do it right" type messages, expands well into the decades.

[1]: https://github.com/Karunamon/dotfiles/blob/1174bbaee047107ea...

"Do what I mean" is great as long is what you mean is what the computer infers. As everyone who wrote Perl or used MS Word knows, this is not always the case. And when it is not, it's often super annoying.

How often do you run apt-get install? I bet it's not even a daily routine. (If it is, you should have already automated it.) OTOH if you run chmod or chown and it suddenly requires root privileges, it's a good idea to think a bit; a disaster may be around the corner.

There are different mentalities; some crave for unconstrained aerobatics while others keep reminding to wear a parachute. I wish you all the luck, but I won't wish you be my SRE.