Thefuck – Corrects your previous console command(github.com)
github.com
Thefuck – Corrects your previous console command
https://github.com/nvbn/thefuck
64 comments
This is the umpteenth app with "Fuck" in its name to hit the front page here. I should try harder to be constructive, but these titles turn me off. Not that I understand the attraction of using an obscenity as a project title, but surely there are more creative obscenities that would suffice.
I run a discord bot for wot blitz and the close to 70 commands are available under about 180 names, based on observed typos people make. Autocorrect on mobile cannot be used (it puts an extra space before the word) and it's sometimes super hilarious to see what people come up with...
Example:
?clantopplayers
aliases=["clanplayerscharts","clanplayers","calntopplayers","calnplayerscharts","calnplayers", "clantoplayers"]
Example:
?clantopplayers
aliases=["clanplayerscharts","clanplayers","calntopplayers","calnplayerscharts","calnplayers", "clantoplayers"]
This sounds a lot like "Do What I Mean" (aka DWIM), which dates back to BBN Lisp, around 1966. See https://en.wikipedia.org/wiki/DWIM
This is cool but I'd rather not have any magic happening when running commands
You have to explicitly turn on a setting to have it run the corrected command without confirmation.
Use this daily. Have it aliased to ‘ff’ though.
Favourite use is pushing a new branch
I used thefuck for a little while, but have removed it since I found this gist https://gist.github.com/robmiller/6018582
The `git publish` alias eliminated the vast majority of my thefuck usage.
The `git publish` alias eliminated the vast majority of my thefuck usage.
This is where I used it a moment ago! Not an error, just faster than the actual command.
Previous discussion (from four years ago -- many commits since then): https://news.ycombinator.com/item?id=9396116
And another (from a year and a half ago, probably the one that prompted me to install it): https://news.ycombinator.com/item?id=14133647
Training yourself to be tolerant of mistakes on the command line seems like a very bad idea. Carpenters have a rule: measure twice, cut once. Train yourself to do the same.
It's almost like typing commands isn't the friendliest human-computer interface. But because we have been utterly incapable of taking the Unix paradigm to the graphical world, we have settled for the error-prone, zero-discoverability atrocity of a command line.
Don't get me wrong, I love the command line because there isn't a more powerful interface, but I'm appalled to see that there aren't any attempts to make it better. 70 years isn't enough to come up with something better?
Don't get me wrong, I love the command line because there isn't a more powerful interface, but I'm appalled to see that there aren't any attempts to make it better. 70 years isn't enough to come up with something better?
It's a combination of the command line itself, and the actual command line apps.
For me, this is the single biggest use case for thefuck:
For me, this is the single biggest use case for thefuck:
$ git push
fatal: The current branch my-branch-name has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin my-branch-name
$ fuck
git push --set-upstream origin my-branch-name [enter/↑/↓/ctrl+c]
(enter)
Same here, but then, I just ran the following and branches are now auto-created
git config --global push.default currentAdmittedly this isn't a concern for all repo setups, but what about the odd time you don't actually want to autocreate a branch?
Saying/typing fuck won't help you now! Basically, thefuck does give some friction and force you to think about things - not much, but maybe just enough.
Saying/typing fuck won't help you now! Basically, thefuck does give some friction and force you to think about things - not much, but maybe just enough.
From the examples, it looks like you’re given an interactive list of ‘corrected’ commands to cycle through, and it won’t proceed until you hit <enter>.
So if you don’t want to do what it suggests, just bail out.
So if you don’t want to do what it suggests, just bail out.
Tab autocomplete works nicely when configured
CLI is like speech. Therefore, I don't get for why people think it isn't a friendly human computer interface since it is so close to the original human-human interface. And just like with speech, things can be ambiguous and easily mistook. The way we've dealt with speaking is just learning to speak clearer, not by turning everything we say into a movie.
> CLI is like speech.
You must be kidding here. CLI is like speech only if imagine you are in a completely dark room full of people, and you can't talk to anyone unless you know their name and their job description, and although you can get a list of names, you need to figure out the job descriptions yourself.
On top of all that, everyone speaks a slightly different dialects, the adjectives and verbs are slightly out of order. And although that's not hard to memorize, you have to speak flawlessly in order to be understood.
You must be kidding here. CLI is like speech only if imagine you are in a completely dark room full of people, and you can't talk to anyone unless you know their name and their job description, and although you can get a list of names, you need to figure out the job descriptions yourself.
On top of all that, everyone speaks a slightly different dialects, the adjectives and verbs are slightly out of order. And although that's not hard to memorize, you have to speak flawlessly in order to be understood.
That's entirely not true, the shell remembers a lot for you,
the current state and the execution of commands can depend in any measure on environment variables and set them, also current directory and time of day, calling script, current history, the name used to call the script (if it has many links), your current line of input (in autocompletion handler).
The shell can also indicate it's state however you want - synchronously, asynchronously, before every input (PS1, PS2, etc.)
The shell can also indicate it's state however you want - synchronously, asynchronously, before every input (PS1, PS2, etc.)
Hmm? Apart from the "dark room" bit, how is it not analogous?
"Get the bag of chips." Who? Which bag of chips? What is the context?
If there is a special context say, there is only one person and one bag of chips, which is similar to there being one file and one program to open it with certain options say, and you do it often enough, an apt shell user would bake that into either an alias or a short shell script. It's rare that I use more than 4 options on a command before baking it into a script. That's very analogous to language: things like slang, contractions, and sayings that make sense in certain contexts form naturally between people or even in some situations, are decided explicitly.
Of course, come times of ambiguity, then you have to explain yourself, just like when a script you usually use as a shortcut doesn't match a certain need, and you crack open the original call, which man helps with, and may be you write another script if need be.
If there is a special context say, there is only one person and one bag of chips, which is similar to there being one file and one program to open it with certain options say, and you do it often enough, an apt shell user would bake that into either an alias or a short shell script. It's rare that I use more than 4 options on a command before baking it into a script. That's very analogous to language: things like slang, contractions, and sayings that make sense in certain contexts form naturally between people or even in some situations, are decided explicitly.
Of course, come times of ambiguity, then you have to explain yourself, just like when a script you usually use as a shortcut doesn't match a certain need, and you crack open the original call, which man helps with, and may be you write another script if need be.
Mostly because when you forget to put a ./ in a conversation with me I don't burn your house down.
Alright, so I want to be careful here, because what I'm going to say will come off as elitist, and it is in a way, but it's helpful because it demonstrates why some of us don't feel the way many of you do, and how you can feel more comfortable if not productive in the shell.
Many of us who work extensively in the shell simply use best practices and hacks in order to not worry or deal with the problems that many of the people in the replies to my comment are expressing. One is "too many options" another, like yours, is "foo" will write zeroes to my drive, if I don't properly include the path. Another is "humans are more understanding of ambiguity" which ignores the myriad times humans do not understand ambiguity. (that said, of course humans understand ambiguity more than computers).
For the too many options, learn to use alias or scripts. The reason for 90 options in commands is not for humans, who can't process more than 5 items simultaneously in the mind's working memory. It's for being able to craft scripts that you can use can use for cases that suit you. Of course, it helps to memorize a couple, but I don't think anyone expects any normal user to remember all of mplayer's options. That's what man is for.
For the ./ bit, there's a reason that . is not in your path. There's a reason there's a path in the first place and it's to avoid doing things you'd rather not. If you worry about being having scripts you write being mistaken based on the path, there is a very smart fix for that, don't name your scripts things like delete,rm,dd,unlink,mount, etc that can be mistaken for commands elsewhere. If you use scripts, best to append an ending to them (.py for python scripts, even .sh for shell scripts although I admit I don't do this) so you can distinguish them. That way, when you try to run doit.py, it won't accidentally doit, at worse, it will complain about not knowing what doit is.
A lot of these bits I learned just by using the terminal. May be there are classes out there, which is great too. Regardless, understand that CLI's have existed for decades and people are extremely proficient in them, and it has nothing to do with people being smarter or more elite than others, they just have practice. The same can be said for any profession, be it carpentering, repairing cars, or selling and presenting. Of course, CLIs can always be improved, but don't discount them completely. There is a reason they have persisted, it's not merely tradition and intertia.
Many of us who work extensively in the shell simply use best practices and hacks in order to not worry or deal with the problems that many of the people in the replies to my comment are expressing. One is "too many options" another, like yours, is "foo" will write zeroes to my drive, if I don't properly include the path. Another is "humans are more understanding of ambiguity" which ignores the myriad times humans do not understand ambiguity. (that said, of course humans understand ambiguity more than computers).
For the too many options, learn to use alias or scripts. The reason for 90 options in commands is not for humans, who can't process more than 5 items simultaneously in the mind's working memory. It's for being able to craft scripts that you can use can use for cases that suit you. Of course, it helps to memorize a couple, but I don't think anyone expects any normal user to remember all of mplayer's options. That's what man is for.
For the ./ bit, there's a reason that . is not in your path. There's a reason there's a path in the first place and it's to avoid doing things you'd rather not. If you worry about being having scripts you write being mistaken based on the path, there is a very smart fix for that, don't name your scripts things like delete,rm,dd,unlink,mount, etc that can be mistaken for commands elsewhere. If you use scripts, best to append an ending to them (.py for python scripts, even .sh for shell scripts although I admit I don't do this) so you can distinguish them. That way, when you try to run doit.py, it won't accidentally doit, at worse, it will complain about not knowing what doit is.
A lot of these bits I learned just by using the terminal. May be there are classes out there, which is great too. Regardless, understand that CLI's have existed for decades and people are extremely proficient in them, and it has nothing to do with people being smarter or more elite than others, they just have practice. The same can be said for any profession, be it carpentering, repairing cars, or selling and presenting. Of course, CLIs can always be improved, but don't discount them completely. There is a reason they have persisted, it's not merely tradition and intertia.
I love the command line for some things and would never trade it, but like anything, I believe it's about using the right tool for the job, and frequently, humans work well with shiny gadgets over memorizing spells.
We've also dealt with it by being extremely flexible, error-tolerant, and context-aware on the parsing end.
> I don't get for why people think it isn't a friendly human computer interface
Because the human is not friendly and has near 0 margin for error.
> The way we've dealt with speaking is just learning to speak clearer,
No, the way we've dealt with that is also to understand less clear speech.
Doo u undrstnd mi? None of those words were even actually correct yet I imagine most people had a good guess at what I said.
An unfriendly human interface that acts like many CLIs:
Hello I'd like a burger
NOT UNDERSTOOD I'D
Hello, can I have a burger?
NOT UNDERSTOOD CAN
Hello, burger?
ERROR ITEM BURGER NOT FOUND
Hello, cheese burger please
Good evening sir, thank you for placing your order.
Because the human is not friendly and has near 0 margin for error.
> The way we've dealt with speaking is just learning to speak clearer,
No, the way we've dealt with that is also to understand less clear speech.
Doo u undrstnd mi? None of those words were even actually correct yet I imagine most people had a good guess at what I said.
An unfriendly human interface that acts like many CLIs:
Hello I'd like a burger
NOT UNDERSTOOD I'D
Hello, can I have a burger?
NOT UNDERSTOOD CAN
Hello, burger?
ERROR ITEM BURGER NOT FOUND
Hello, cheese burger please
Good evening sir, thank you for placing your order.
How about
man 6 mcrestaurant
mcrestaurant offers... cheese burgers
man 6 mcrestaurant
mcrestaurant offers... cheese burgers
Every time this point comes up, ultimate conclusion isn't the CLI is bad or can't be improved, but the VT220 and similar emulation that's holding things back. Any person who has developed a terminal emulator can attest to that. There have been and are attempts at a much better CLI, but until we drop the legacy baggage, we can't have nicer things, at least in a sane way. But if we do that, we don't really have enough incentive to use the newer tools. Its a catch 22 after all.
Mh, did you ever tried modern shell like zsh or fish, with a reasonable config? Or even better, despite a bit steep learning curve, eshell (Emacs) if you already know Emacs and elisp a bit or xonsh if you are already familiar with Python.
As an Emacs (EXWM) user I agree that pure CLI is limited and pure text-based interfaces without terminal emulators limits are far superior but... Well, today outside Emacs we only have CLIs, the rest is so limited and limiting that can be used only for desktop end-user stuff. Even Microsoft Windows mandate CLI for serious system use/management...
As an Emacs (EXWM) user I agree that pure CLI is limited and pure text-based interfaces without terminal emulators limits are far superior but... Well, today outside Emacs we only have CLIs, the rest is so limited and limiting that can be used only for desktop end-user stuff. Even Microsoft Windows mandate CLI for serious system use/management...
Sounds like someone needs to just Do it.
> zero-discoverability
Is your TAB key broken?
Do the letters `ls` and `grep` not work on your keyboard?
Is your TAB key broken?
Do the letters `ls` and `grep` not work on your keyboard?
To be fair, tab helps you discover commands about as well as a dictionary helps you discover words. I'm personally looking for something like apropos, but much more powerful.
Closest I could think of would be 'man -k', but a apropos would be cool
Tab completion makes it significantly better. It's a bit like syntax highlighting. If it doesn't tab complete properly then something is probably wrong.
It's funny but tab completion makes CLIs a completely different experience. That and (yes) insert mode. If you've ever dealt without either it becomes much more of an exercise in precision and patience.
I have a linux distro for you: https://qntm.org/suicide
UAU, nice :D
anyway, for accidental files operation protection nilfs2 is a very effective protection, despite super-slow development and actual limited features, it's rock-solid, mainline, live resizable (both grow and shrink) and in years does not loose a bit of information for me :-)
anyway, for accidental files operation protection nilfs2 is a very effective protection, despite super-slow development and actual limited features, it's rock-solid, mainline, live resizable (both grow and shrink) and in years does not loose a bit of information for me :-)
this is amazing. thanks for sharing.
To that end, I highly recommend the command line utility 'sl', which runs an unskippable ASCII animation of a steam locomotive. Makes for great fun explaining it to the flummoxed coworker borrowing your computer!
Seems really cool in general but I wish it corrected gitp ush to git push instead of git ush. That sort of thing is a fairly common typo for me :\ Still, I expect I'll find it very useful.
It's possible to configure git so that git ush becomes git push; for example, this .gitconfig correct many common misspellings: https://github.com/AgalmicVentures/Environment/blob/master/c...
Obviously such corrections should be used judiciously.
Obviously such corrections should be used judiciously.
I used this for a while, but it added a lot of time to start each shell. Might not be an issue for you, but might save you some time if you are wondering why it takes a full second to open a new shell.
I had this sitting in my .bash_profile for a while. I removed it after I realized it was adding like 2 seconds of lag before my terminal finished loading.
Just hopping on this thread post for a shameless plug:
https://github.com/Detry322/git-psuh
Why make errors do the thing you want, when you can make them do things you don't want? ¯\_(ツ)_/¯
Carpenters have "measure twice, cut once", since there's risk involved with a mistake. Let's make mistakes risky.
https://github.com/Detry322/git-psuh
Why make errors do the thing you want, when you can make them do things you don't want? ¯\_(ツ)_/¯
Carpenters have "measure twice, cut once", since there's risk involved with a mistake. Let's make mistakes risky.
"I've cut the board 3 times and it is still too short!"
I built a bathroom with a heated floor last year. For that floor I needed 42 m of heating cable. This cable is poured into the flooring screed and as such can not be spliced, it has to be in one piece.
Ir ordered 42 m and got a parcel with 18 m in the mail, apparently the person who processed the order mistook the order sequence number - 18 - for the ordered amount. I notified the supplier about this mistake, added some photo's of the cable - which is helpfully marked in meter-increments - and told them to send a new cable as I ordered 42 m.
The supplier sent 24 m of cable.
Ir ordered 42 m and got a parcel with 18 m in the mail, apparently the person who processed the order mistook the order sequence number - 18 - for the ordered amount. I notified the supplier about this mistake, added some photo's of the cable - which is helpfully marked in meter-increments - and told them to send a new cable as I ordered 42 m.
The supplier sent 24 m of cable.
This genuinely made me chuckle.
That said, if mistyping ‘git push’ is a common occurrence, why not just define an alias?
That said, if mistyping ‘git push’ is a common occurrence, why not just define an alias?
Even better, git supports correction of misspelled commands, but you have to turn it on:
git config --global help.autocorrect 1
gti—>git...
so it's not just me then? I feel better now, thanks :)
so it's not just me then? I feel better now, thanks :)
Thanks! I hate it :)
Spare the rod, spoil the child!
Nice, not really useful for me (I can correct by hand, probably at the same or higher speed and with more predictable results) however nice and scenic.
Perhaps it work better inside zsh/fish autocorrection, extended it to another level :-)
Perhaps it work better inside zsh/fish autocorrection, extended it to another level :-)
softinio(2)
This is pretty cool I usually do the following
>aptget install oops
ERROR!!
>^t^t-
>apt-get install oops
WIN
The part where it gets insane is when you realize that you don't have to type apt-get and apt only is enough, because you are not a script and (probably) don't care about different output formats.
That blew my mind and cut a lot of mistakes!
That blew my mind and cut a lot of mistakes!
What about `fc` (fix command)? It's been in unix forever.
$ echoo "hi"
-bash: echoo: command not found
$ fc # this will open your editor to fix the command.
echo "hi"
hiBig previous discussions:
https://news.ycombinator.com/item?id=14133647
https://news.ycombinator.com/item?id=9396116
https://news.ycombinator.com/item?id=14133647
https://news.ycombinator.com/item?id=9396116
I'm surprised at how serious people are being in the comments... This is amazing. My team and I had a good laugh. Great work.
It might be that I just type fast - I do - or it might be that the cognitive load imposed by using 'helpful' tools like these is higher than the simple act of machine-gun-typing out a corrected version of the command.
Repeatedly typing out a command also has a bit of a satisfying "now you listen to _me_ you frickin' pile of silicon" to it, maybe that plays a role as well. On the other side it could be viewed as a form of self-flagellation, doing penance for the sin of not typing out the correct version in the first place. Whatever its virtues, it seems to work for me.