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.
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.
Whether it is this `fuck` command, an earlier `dwim` command or any of the helpful shells or missing command tools which provide me with suggestions, for some reason it still seems to be faster to do it the way I've been doing it for years:
some_long_commnd^C
some_long_command --wthi^C
some_long_command --with these --optoin^C
some_long_command --with these --options
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.
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...
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.
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 :-)
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.
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.
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?
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:
$ 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)
I'm pretty unrepentant about that one - I _could_ waste brain cells on keeping track of whether my branch already exists upstream, and I _could_ waste keystrokes typing out the more verbose command myself. But I'm not gonna. Life's too short.
Admittedly 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.
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.
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.
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.
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.
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.)
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.
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.
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...
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.
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.
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 :-)
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!
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.