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."
That's funny. Never thought about that. I guess Emacs people think of it as yanking from the clipboard to the document, and Vim people think of it as yanking from the document into the clipboard.
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.
Yep, and "nex/nvi are intended as bug-for-bug compatible replacements for the original Fourth Berkeley Software Distribution (4BSD) ex and vi programs."
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
I want a terminal that highlights things it thinks are off. Like when I type cd cd or git git. But I don't want it to auto fix nor wait until the command is issued to complain.
This is because I want to be the sole controller of what command is actually issued. Call me an old curmudgeon but I just don't trust the auto fix solutions.
for a in $(git var -l | sed -nE 's/^alias\.([^=]*)=.*/\1/p') ; do
if ! command -v g$a >/dev/null 2>&1 ; then
alias g$a="git $a"
fi
done
Which creates a shell alias prefixed with `g` for each of my configured git aliases if there is no conflict. So I get not only the `gst` command you mentioned and ones like `gco` (because I have Subversion-equivalent aliases for common commands), but more complex ones like `gstpup` (stash, pull upstream, stash pop). Combined with `alias g=git`, I seldom type "git" and the setup is pretty convenient. I've thought of making the above alias unconditionally, or report conflicts, as it can be jarring when an alias is missing. I've also considered expanding it to all git commands because sometimes my custom ones live as `git-$command` scripts and not aliases.
For me, it's because `gst` will only work on my machine. I like feeling at home on any system, so I'm loathe to depend heavily on aliases and configuration. One of the things I like about git git is that it appears to improve my experience without significantly affecting my habits.
I used to do that, but I found it wasn’t actually saving me any cognitive load.
My newer philosophy toward git aliases is the one described here: http://gggritso.com/human-git-aliases. After reading this I totally overhauled my .gitconfig and replaced it with the one described here and I’m a lot happier.
I don't use either one anymore. I've switched to magit, which is faster than both and can also give you interactive menus and reminders of commands if you want.
Why type 'gst'? I use C-x g, which is bound to magit-status:-)
Somewhat more seriously, I haven't had to worry about typing 'git git' because I haven't typed 'git' on a daily basis in years. I think I've probably typed it once in the last month.
The mathematical term for a function that is the same when applied multiple times giving you the same results is called "idempotent" which translates to "same power". f^n(x)=f(x) for some positive natural number n and any x.
I had a senior dev interview with a major company in SV last year where the lead and hiring manager claimed that the description for this behavior was "side-effect free".
I didn't want to ruin my chances by correcting him that side-effects and idempotence refer to different qualities.
I passed the interview, but I've never forgotten that. The guy also seemed to have washed into the interview off his surf board.
Oh well. It was a very major company, so I let it all go.
I understand 'idempotent' not as 'having no side effects' but as 'having the same side effects whether performed one or many times'. This is side-effect free:
Mathematical idempotency depends heavily on the function's domain. It's not too challenging to construct a non-idempotent function that has an idempotent restriction. So depending on what your domain of interest some operations may be idempotent or not.
In the hello world example, I guess we are considering 'echo' as the function. If then if we consider stdout and echo's args to be the same, echo will be idempotent.
However, stdout and command args are pretty different things on any system I know. If we care about things like command line history, then clearly 'echo hello world' is not idempotent.
I disagree that your ‘ echo hello’ example is free of side effects. It writes to stdout. It overwrites $?. It changes the value of the last executed history command. Etc.
About the only side effect free operation at a blank line terminal prompt is _probably_ hitting enter or ctrl c. Or ‘#something<Enter>’
But your idempotency examples are spot on.
Basically, idempotency is a very useful concept. Side effect free isn’t.
> I disagree that your ‘ echo hello’ example is free of side effects.
I posit that you understand perfectly well what i was getting at! If it helps, imagine that you are spawning a fresh shell to execute each command line, through system(3) or some such.
> safe operations are a subset of idempotent operations
Definitely not. 'Safe' means too many things in different contexts to make sweeping statements like that.
Here's one i came across recently. You are interacting with a stock exchange. You have sent an order to buy 100 shares of Twitter stock at some price, and it is now resting on the order book, waiting for orders to sell at that price. You see that the character limit on tweets is being increased, and decide that you don't want to buy 100 shares, but only 90, so you send a message to modify your order. At the same time, two other people, who have also seen the news, decide to dump their holdings of 90 shares each by sending sell orders at the price you are bidding. Their messages arrive just before and after yours. What happens?
If the message to reduce your order is a nasty non-idempotent one which says "reduce my order by 10", then:
1. First seller's order to sell 90 matches your order to buy 100; you buy 90, and your order is reduced to one to buy 10
2. Your modify message reduces your order of 10 to 0
3. Second seller's order to sell 90 arrives, but has nothing to match with
You have successfully bought 90 shares, well done.
If the message to reduce your order is a nice safe idempotent one which says "change my order to 90", then:
1. First seller's order to sell 90 matches your order to buy 100; you buy 90, and your order is reduced to one to buy 10
2. Your modify message increases your order of 10 to 90
3. Second seller's order to sell 90 matches your order to buy 90; you buy 90, and your order is reduced to 0
You have bought 180 shares. Oh dear.
This is not hypothetical. More than one new exchange has launched with a protocol where orders are modified to a target amount, rather than by a target delta, and changed it some time later, after their users got themselves in a pickle.
You can do a bit better by making the modify message a compare-and-set, so it only changes the quantity to 90 if it is currently 100. In that situation, the modify will fail, and the second order will sell you 10 shares. That's still not as good as the non-idempotent message.
> (I suspect you meant “safe” in a different sense, but I couldn't resist.)
The moral of this story is that computer scientists should not be allowed to use the word "safe"!
> > safe operations are a subset of idempotent operations
> Definitely not. 'Safe' means too many things in different contexts to make sweeping statements like that.
The intended reference (which I hoped would be recognized generally in this audience) was to he definition of “safe” and “idempotent” in HTTP (see section 4.2 of RFC 7231.)
(In your example, neither operation is “safe” in the HTTP sense; all state-modifying operations are unsafe.)
I agree with you generally that talking about 'safe' may be misleading. However, I don't think your example shows that idempotent operations can be 'unsafe' - I think it shows that the translation of user's intent to a system operation was lossy. The user's intent was to "buy a total of 90". Translating that to "Set my current order to 90", regardless of the idempotency of the operation, is not accurate, for precisely the reasons you stated. Neither is "reduce my order by 10", because the user may attempt to send the message "set my current order to 90/reduce my order by 10" multiple times(just to make sure it went through), and then they would get to buy less than 90 shares.
It would take different data structures and a different API to translate the user's intent correctly, and then the idempotence of the operation may be important. For example, if the order had a "total" and "current balance", you could be sending a message to set the total to 90(which would internally reduce the current balance), and since that message is idempotent, it's safe to send it multiple times.
I disagree that this is common the world of software, and I disagree that the WP article that you linked makes that claim. I humbly suggest that you might benefit from reading that article more carefully.
You're right, I meant to summarize more along the lines that calling something multiple times doesn't cause more than one set of side effects. Unfortunately too late to edit by the time I re-read it!
It’s funny because if you read what they wrote, they’re fully aware of the difference between the two (since they reference the HTTP RFC definition of the idempotency of PUT and DELETE).
That difference is somewhat subtle and I had to read the description in the sibling comment to understand it. I would have welcomed a correction from somone I was interviewing.
On a side note, the founders of Google once tried to explain recursion and idempotence to Terry Gross on NPR. It's pretty amusing. It starts at 13:45 into the interview here:
You may have just been victim to the "let's see if they take a risk and correct me on my BS" test some interviewers give. Or they just didn't get it, that happens too. Some won't admit they're wrong even in the face of a mathematical proof..
You are right, I checked and the resulting sub-process tree is the same regardless of whether !git or !exec git is used.
Also, I found one caveat from the same docs:
> Note that shell commands will be executed from the top-level directory of a repository, which may not necessarily be the current directory. GIT_PREFIX is set as returned by running git rev-parse --show-prefix from the original current directory.
So, if I have a modified file `bar` in subdirectory `foo` under project root, and I am currently in `foo`, git status will show:
erm, "git git foo"; in most shells can be fixed with "!*" as your next command. Repeat until lameness subsides.
Seriously though, I don't understand why people want to hide obvious errors like this - I'd much rather have the tool fail to execute than potentially perform some action I wasn't expecting.
Exactly. If anything I appreciate when errors are _highlighted_ a la `sl` (Steam locomotive) for `ls` or the `gti` for `git` that has a golf gti run across the screen
While the cleverness is admirable, there comes a point in your life when you realize you really do always want your own errors to fail loudly and immediately.
`!exec git` caused my shell to exit. I have a lot of stuff wrapping git in my shell though (including a bash function wrapping git itself!). The author himself only pushed up the change to his own gitconfig a few hours ago. It was previously `!$SHELL -c \"git $*\"`.
My version that works for my setup is `"!f() { git \"$@\"; }; f"`.
Hope this helps anyone who ran into the same issue, although I'm not 100% confident about the quoting.
EDIT: fixed the quoting, as per cryptonector's suggestion
EDIT2: need to quote the quotes for gitconfig to use it correctly
Well... If you have this problem (I really don't), then you probably have it with more than just git, and the proposed workaround would be "a local solution to a global problem".
I have homegrown aliases
like 'tags' 'rdel' (git push origin --delete) 'ldel' (git branch --delete) and many more combined with Zsh's (Oh my Zsh)'s several aliases (e.g ggpull, glog, gp, gc) etc.
This reminds me of something I read long ago that was along the lines of "make the computer change for you, don't change for the computer". As such, I have a small list of common typo's that I make that alias themselves to their correct forms.
Since then, I've found that these aliases have been the best workflow improvement I've ever made.
This is nice specifically because of the way the author uses `exec`. Without meaning to be patronizing, there must be lots of people reading the thread who don't know what `exec` does, and why it's a neat solution to this problem (or non-problem, whatever your view is); I'd say do look it up if you're interested in programming.
I sometimes have this problem but I hate solutions like this because I figure if I make this kind of mistake, I'm not paying sufficient enough attention to what I'm doing at the moment.
I take a minute, clear out distractions and then come back to what I'm working on.
The danger of this is if you accidentally write 'git git something' into a shell script and it works on your machine, then you commit the script to a repo and it doesn't work for anyone else.
One way around that issue is to prefix commands you intend to share with backslash:
$ \gstatus
gstatus: command not found
vs
$ gstatus
git status stuff
The backslash just disables alias expansion. This works on all shells I'm aware of. It won't help with other portability concerns like actual missing commands though, of course.
I find writing shell scripts is a different mental process than interacting with the commandline, so I think the problem of “starting a command then leaving the terminal” is non-existant in that context.
It would be cool if you could generalize this for anything (e.g. ls ls -al). That being said, I wonder if there's any actual command-line utilities that actually use a similar syntax to perform something useful.
I often type "git stats" but I've never felt the need to go through all of this just because I'm lazy. Then again maybe that's an ironic example of laziness.
Why is this a problem? Is the author blind? If this happens with git then surely it happens with every command. What about "rm"? What if I type "rm -Rf", leave, then come back and type something else? Maybe a better solution is to change behaviour, or if there really is some reason for this behaviour, have something delete the currently entered command after it's been idle for some seconds.
Does anyone else actually do this besides OP. I've never heard of this problem until now.