Thefuck – Corrects your previous console command
github.com
github.com
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.
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.
That said, if mistyping ‘git push’ is a common occurrence, why not just define an alias?
git config --global help.autocorrect 1
so it's not just me then? I feel better now, thanks :)
$ echoo "hi"
-bash: echoo: command not found
$ fc # this will open your editor to fix the command.
echo "hi"
hi some_long_commnd^C
some_long_command --wthi^C
some_long_command --with these --optoin^C
some_long_command --with these --options
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.
Example:
?clantopplayers
aliases=["clanplayerscharts","clanplayers","calntopplayers","calnplayerscharts","calnplayers", "clantoplayers"]
>aptget install oops
ERROR!!
>^t^t-
>apt-get install oops
WIN
That blew my mind and cut a lot of mistakes!
Perhaps it work better inside zsh/fish autocorrection, extended it to another level :-)
Obviously such corrections should be used judiciously.
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?
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...
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)
git config --global push.default currentSaying/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.
So if you don’t want to do what it suggests, just bail out.
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.
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.
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.
The shell can also indicate it's state however you want - synchronously, asynchronously, before every input (PS1, PS2, etc.)
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.
man 6 mcrestaurant
mcrestaurant offers... cheese burgers
Is your TAB key broken?
Do the letters `ls` and `grep` not work on your keyboard?
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 :-)
The `git publish` alias eliminated the vast majority of my thefuck usage.