I just ran across Language Tool[0] recently. Free, open-source proofreading lib, can be run totally locally. Uses Google Ngrams to check for often confused words. Didn't correct "doe snot" in my synthetic test just now, but that seems like a plausibly minor extension of existing functionality.
There’s at least one product trying to address the issue with “valid, but probably wrong” typos. It’s called Grammarly and for some unfathomable reason it gets advertised to me a lot on YouTube whenever Google detects I’m in South Korea; I believe they are seriously mistargeting their marketing efforts.
(That said, if it were me, I’m not sure if I would give up typing doe snot every once in a while.)
The spell checker in Chrome can already do that to some extent. For example, "The men walked over their to grab they're food." gets corrected: https://i.imgur.com/NR4zyVA.png
command-not-found [1] could implement that, if it isn't implemented already. I remember a Linux distribution with an application which would let a train pass in a few seconds after typing typical commands wrong. Trust me, you'll learn to type correct when that happens because it is very annoying.
Our org has a bunch of related miscellaneous projects called "pantry". Basically, if it doesn't fit standalone, you put it in the pantry. It works out better than you think, except when someone is doing a webex and misses an r.
Depends on the importance of the system. If it's a fairly unimportant home system that's excessively backed up, it's fairly easy to live life on the edge.
An alias would work but it wouldn't say rebnooting. That was my initial fix. But I was learning things at the time and I learned how to recompile parts of the distribution. I also learned how programs in Unix could invoke different effects based on name. Coming from DOS, it was a real surprise that reboot was a link to shutdown.
Yes! I do all of those things too. git git, vim vim, and 'gi tpull' and 'gi tpush' and everything.
I think any command where you might start to type something out, but then need to refer to another window or session to figure out what else you want to type, is vulnerable to this kind of mistake.
Got a weird idea reading this. How about checking for all 127 error codes returned by $? (this is the return code that the shell gets, following a failed command, due to command not found).
This process should happen behind the scenes. And then train a RNN for translating it to the following command, which returns a success code. Perhaps, we need to add a few checks that successful command has the same intent as the one which returned 127 error code to the shell.
alias g='git status -sb'
alias ga='git add'
alias gac='git commit --amend'
alias gb='git branch'
alias gbb='git checkout -b'
alias gbm='git branch --merged'
alias gbn='git branch --no-merged'
alias gc='git commit -m'
alias gcp='git cherry-pick'
alias gco='git checkout'
alias gd='git diff'
alias gdc='git diff --cached'
alias gg='git status'
alias gl='git log --graph --pretty=format:"%Cred%h%Creset -%C(auto)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset" --abbrev-commit'
alias gla='git log --all --graph --pretty=format:"%Cred%h%Creset -%C(auto)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset" --abbrev-commit'
alias ggpublish='git push && git push --tags && npm publish'
alias gp='git pull --rebase && git push'
alias gpp='git push && git push --tags'
alias gpl='git pull --rebase --prune'
alias gpt='git pull --rebase && git push --tags'
alias grb='git rebase'
alias grc='git rebase --continue'
alias gsp='git stash ; gp ; git stash pop'
alias unfuckgitremote='git branch --set-upstream-to=origin/`git rev-parse --abbrev-ref HEAD` `git rev-parse --abbrev-ref HEAD`'
I have to admit I use `unfuckgitremote` more often than you'd hope.
Personally, I don't want my typos corrected when I enter commands. I prefer the negative reinforcement to encourage fewer errors. I also don't mind an occasional error.
I often type "git clone ", then switch to a browser to copy/paste the URL, which is usually fine, but there are still many times where I've happened to include "git clone" in the copied string. (So I end up with "git clone git clone $URL").
I think that advice got warped/lost in translation: Wasn't the original advice "dont't paste stuff copied from web pages into the CLI"? - Because a bad page could covertly change what is actually copied via JS.
That danger doesn't apply when things are copied from the browser chrome (address bar) or other locations. So why would pasting then still be dangerous?
I think blindly passing on advices "because $SECURITY" can actually detrimental to security because you may end up with half a dozen esoteric practices without actually knowing what they defend against. (I know the parent was half-joking, I think that's a more general problem)
Certainly. The user is either used to typing "git clone" or is using a GUI where you input the repo URL. How bitbucket does it would only be fine if you only use bitbucket or if everybody did it that way.
Hexchat closing on C-w is such a pain! It can't be scripted away either because it's hardcoded in the source. I haven't looked into this for some time but there does seem to have been some updates.
One of the things I appreciate about macOS is that it implements some of the emacs behavior (C-a, C-e, C-k). Unfortunately not C-y, and non of the M- ones work since that's for special characters. I understand they originally come from the readline library.
In other words ctrl-w is "kill," which is what most people would think of as "cut," and ctrl-y is "yank," which is what most people would think of as "paste."
Guilty as charged. I'll commonly start typing git, think about something else, switch to my editor, browser or an other terminal tab, then come back and type "git <command>" in full.
Something I have noted as part of my venturing into mechanical keyboards lead me to the revelation that many of my "mistakes" were really the keyboard failing me (ie, not properly register my keystrokes). All my life I assume was me the idiot that not know how use it. Only after I pay attention to how I use the keyboard (looking at my hands for a while) I start to see this.
So, I need to more firmly hit the keys in my actual driver (MS Ergo Keyboard) and now building my own mech...
P.D: ie: Maybe one of the different mech switches are more suited to the way YOU type:
P.D 2: This is a reply to all the ones that state that type wrong some commands.
Also, and maybe more common, is just bad typing. I was far worse before the use of the MS Ergo Keyboard (it DEMAND to use both hands.) So, if the performance change by keyboards (happend to me) maybe is a indication that are the tools at fault here..
This happens to me all the time on the new Macbook keyboard, especially with the arrow keys. I can watch myself press the key and see nothing happen. I really need to switch to a good external Mac keyboard.
I totally do this. I also occasionally will have something breaking and soon realize I typed 'git' randomly in the middle of a file instead of in my terminal...
I do stuff like because I alt-tab a lot and have so many similar-looking windows open. It's not just me either, I have seen stuff like "git pull" posted in chat rooms followed by "oops wrong window".
It ships nvi, as do the other BSDs. I think it's reasonable, BSDs have a stronger divide between the base system and third party packages, I'm not sure it would make a lot of sense to maintain vim as part of the former.
Besides on my FreeBSD system /usr/bin/vi is around 400kB while on my Debian machine /usr/bin/vim.basic is 2.4MB. It's not much these days but on embedded platform it could still make a significant difference.
Debian is the same way. But as soon as you open a file with vi on a fresh install, you know it isn't vim, so you close the editor, install vim, and then the vi command opens vim.
It's usually more "type git in a terminal then open a new tab to look something up and ALT-TAB back to the terminal" rather than a physical going away.
As a related issue, it bothers me a lot when I type some command that I want to read the output, and then I proceed to run `ls` right in the sequence and move the output out of the screen.
Surprised how many are affirming this. Kind of a DAE moment. My fingers are a bit more tame from having spell check disabled & not falling back on these typo-aliases, as shown by the author's other aliases. Especially their t-prefix aliases which imply zsh aliasing gi to git
I sometimes do, though not specifically with git. Can be emacs, can be ls, can be anything where I interrupt my thought process.
So... I really fail to see why this article is of any relevance at all, really. Or at least a more global solution would have been better, but I think it's not really an annoyance. For me, it's the same as wanting to fix a UI so that I wouldn't re-double-click a software that I've already started (well, some prevent it, and generally when they do, it means there are sessions, and it annoys me).
I do the same with man instead (even though I only used that program like 50 times the last year) … it even happens in any other program where you can input text …
It happens to me when cloning a repo. Sometimes I just write git clone ..., go to browser and the command already contains git clone, then i end up having sth like git clone git clone ...
I aliased 'g' to 'git'. Combined with git aliases ('st' for 'status' etc) this is almost as short but doesn't steal all the short names from your shell. So instead of 'gs' you have 'g st'. Upside is you save two letters even on uncommon git commands :)
I just type git (or more commonly ls/cd) once on auto pilot because I'm at a terminal then without thinking about it hard I'll type it in consciously because that's why I'm at a terminal. It doesn't even involve looking away
Finally I've written a small shell function that corrects "gi tpull" to "git pull", because that happens at least once a day.