While I agree with what I take to be your overall point, what would have been lost had you replaced your comment with the following, which does not assume anything about the poster's motivation?
The utility is actually called "The Fuck", with no asterisk. Please respect creators by not bowdlerizing the names they have chosen.
I'm not sure if this is too much of a de-rail, and I will delete it if it is inappropriate, but I am constantly surprised by and grateful for the civility of HN, where, despite strong opinions, constructive criticism is often accepted and acted upon. Thank you for being part of that!
Created a pull request for a `fuck -dry` option.
Did not test nor store the command so when it is ran again it is recalled, but the base is there for it to be fully implemented.
Yeah I agree...the appeal of CLI is to tersely do a variety of powerful commands...and the tradeoff is that you have to be exact in your syntax. The seconds saved in not having to retype something is a relatively irrelevant optimization, which isn't bad in itself except that it also introduces a significant amount of ambiguity, which can be deadly in CLI work.
Or syntax highlighting as found in fish, red if your command will not run, blue otherwise, params in blue. Duno I wish more shells had basic syntax highlighting for input commands.
I think a good solution to this would be to have it display the command it's going to run with a y/n prompt. It would only add one extra keystroke and make the utility a lot safer. I think I'll make a pull request or fork or something that does this this weekend if somebody hasn't already by then.
It's basically a negative, aggressive emotional response, exactly a thing I'd rather not experience while working.
A failure due to not enough privileges might be a signal to rethink what you are doing; a mindless prepending of `sudo` is dangerous. Why not `su root` then?
Also, there was that screnshot of `sudo wget` as a response to a 403 error. This is exactly why you should re-examine a failed command instead of swearing around.
I would, because a lot of commands could be improved by a "do what I mean" option.
GNU find is smart enough to tell me that I've placed one of the flags or the find string in the wrong place, but not smart enough to correct the fucking error and do what I meant in the first place. (It knows, it just won't do it.)
"apt-get/yum install" is unusable by anyone but root. Why do I need to waste time re-keying the command? This is annoying enough that I've aliased it[1] on every machine I have access to.
I'd be willing to bet the collective man hours wasted on these worthless "you did it wrong, here's how you did it wrong, now go do it right" type messages, expands well into the decades.
"Do what I mean" is great as long is what you mean is what the computer infers. As everyone who wrote Perl or used MS Word knows, this is not always the case. And when it is not, it's often super annoying.
How often do you run apt-get install? I bet it's not even a daily routine. (If it is, you should have already automated it.) OTOH if you run chmod or chown and it suddenly requires root privileges, it's a good idea to think a bit; a disaster may be around the corner.
There are different mentalities; some crave for unconstrained aerobatics while others keep reminding to wear a parachute. I wish you all the luck, but I won't wish you be my SRE.
I think it's a funny little app. I could see it being kind of useful for the author but I think I would personally have trouble using an app that I don't actually know what it's going to do 100%. I think that you could mitigate this a bit by putting the list of commands it corrects right at the top of the readme.
I think most of us have probably been at the point where we were typing something like "I hate you, you god damn computer!" into the terminal or text editor. I see this as a moderately elegant helper in those situations
'I could see it being kind of useful for the author...'
That was my impression. It reminded me of little custom scripts or functions I've created that help with my day to day work, things I wouldn't necessarily give to someone because they were built with myself in mind. I know how they work and exactly what they do.
And then update it whenever the upstream changes. And keep track of all any new references which need to be modified. And publish a package if you still want it to be installed easily. And so on.
Swear words don't break the HN guidelines. When we ask for civility we have in mind how people treat one another online. Swear words can be used to treat others badly, but they have plenty of other uses.
It's not a trivial question, though, and people aren't wrong to disagree. Cultural differences make for very different views here. In some (sub-)cultures swear words are uncivil and in others they are innocuous. There's no model that satisfies all these norms, so inevitably we have to disappoint some.
As a consequence of the above, we don't bowdlerize titles either.
I know a guy that does all his "printf debugging" using variations of printf("penis\n"). As a bonus, its a good incentive to remember to get rid of the printfs when you are done :)
Guys, we've spotted the Mormon here... he was this close to pooh-poohing that article about the positive productivity effects of coffee, but a curse word used in an extremely minimalist command-line tool has gone too far!
help.autocorrect
Automatically correct and execute mistyped commands after waiting for the given number of deciseconds (0.1 sec).
If more than one command can be deduced from the entered text, nothing will be executed. If the value of this option is negative, the corrected command will be executed immediately.
If the value is 0 - the command will be just shown but not executed. This is the default.
> WTF means the same thing. That is no less vulgar.
Vulgarity of expressions is not a function only of what the expression means, but of the acceptability of the expression itself in various social contexts. WTF is, generally, acceptable as not excessively vulgar in social contexts where expanding the last letter of the initialism into its referent would not be, but the reverse isn't true; WTF is pretty close, therefore, to strictly less vulgar.
This may not seem rational, but then the entire concept of vulgarity is irrational.
"The f-word" is used exclusively by people being descriptive. Nobody says "So I was f-wording my spouse..." or stubs their toe and exclaims "oh f-word!". It is used when people are reporting what other people said. That is why it is considered less offensive; it is never properly used.
It signals to the easily offended, "I want to convey this information to you, but I am deliberately mangling words so that you know I too disapprove of the terrible word that was unfortunately used by somebody else."
"WTF" isn't used that way. When people say it, they are using it, not describing somebody's usage. There is zero implication of an apology or empathy with the audience's word-phobia.
There's already a "wtf" program, available in Macports and probably some other package managers. It has a database of internet acronyms, and otherwise it seems similar to commands like "apropos" and "whatis".
~> wtf is imnsho
IMNSHO: in my not so humble opinion
~> wtf is cat
SVK::Command::Cat(3pm) - Output the file from depot
cat(1) - concatenate and print files
fc-cat(1) - read font information cache files
git-cat-file(1) - Provide content or type and size information for repository objects
~> wtf is fuck
fuck: nothing appropriate
Projects like this always make me think the developer's imagination has drastically failed them with respect to the scope of negative consequences that may result from using their tool.
Projects like this always make me think the developer's imagination is great and they must at least be intelligent enough to criticise their work (with humour).
who@where:~$ fuck
No fuck given
who@where:~$ fuck
fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
/dev/sda6 is mounted.
WARNING!!! The filesystem is mounted. If you continue
you ***WILL*** cause ***SEVERE*** filesystem damage.
Do you really want to continue<n>? no
check aborted.
I think i will continue using the Fish shell feature instead. It has this awesome feature of autocompleting your command with the bash history of yours.
It is safe because it will autocomplete a command that you wrote before.
Another cool thing with it is that, it will list the commands that you can run after entering a word. It does this by reading the man page of the command you write.
brew <Tab> will list the brew commands for you to use with its explanations.
yea, lots of us use shells with suggestive text...that doesn't make this less amusing. Now if only someone would make rules for my osx terminal, thatd be great
Cool idea. For those systems where you don't have the option of adding a 3rd party tool, it's probably worth knowing some of the standard bash shortcuts. The easy to remember ones are:
!^ - the first argument from the previous command
!$ - the last argument from the previous command
!* - all of the arguments from the previous command
!! - the entire previous command
*Works if properly implemented. Had to manually disable this behavior in eshell as it prevented you from running regex with two carets, e.g. '$ grep -E '^sometext[^ ]+moretext'.
You can also just run a sed style substitution in most shells, e.g. '$ !!:s/before/after/' or '$ !!:gs/x/y/', which is safer IMO.
You know... I've seen this notation on discussion forums (and probably IRC etc.) for years, and had no idea until now that it was a reference to this shell capability lol
I've been using "sudo !!" (which I pronounce as sudo bangbang in my head) for a while now, mostly with vim for editing stuff in /etc. It's very nifty.
Another nifty tool is vi editing mode. You run "set -o vi", and now your shell takes vi modal editing commands. That along with Ctrl-r for reverse history search has made life in the shell so much easier. Bash has a ton of little stuff like that built in. Zsh has a few more.
Yes, that vi editing mode of bash is very useful. IIRC it was there in ksh too. Some people might not know that you can use both the insert/append mode and the command mode of vi(m) in that vi editing mode of bash, to edit previously entered commands. You just switch between the two modes the same way as you do in the real vi(m), with ESC to go from insert/append mode to command mode, and i or a to go from command mode to insert/append mode.
Also, after you have entered a previous command, to edit it, or any previous command in the history, the first thing you have to do is press ESC (to go to command mode) and then k, thereby bring the last entered command into view for editing.
When editing a command, but in command mode (not insert/append mode), you can also press v to open the command in vi(m) in a temporary file, then have the full screen editor at your disposal to edit the command (useful for long scripts including for/while loops or long pipelines), and then when you save and exit (:wq or :x followed by Enter), the newly edited command gets executed by bash.
Also, this editing technique is useful not only for correcting typos in commands, but for modifying a previous correct command, to change some words in it and then re-issue it.
Nice. Now that we're getting all stackoverflowy in here, it would be worth mentioning two other handy tips.
Preventing typo mistakes with bash autocomplete is even better than correcting mistakes afterwards, it also makes typing so much faster.
It works with commands AND it also works for files inside the current working directory.
Hint: start typing your command and then hit TAB, voilà!
Note: if there are more than 1 command/file option that starts with the same chars you wrote, hit TAB twice and you will have all the options displayed in front of you, it comes in handy to remember fast instead of browsing documentation.
When I was typing the '#' I was thinking 'comment', not 'root shell'; in retrospect I can see how it might have been confusing, especially when my example used 'sudo'.
I was not criticizing your use of # at all. Using # to comment is perfectly fine I guess. Now that you mentioned it, it might be a bit confusing for newbies, but don't worry I don't think anyone would try to send the command 'Crap' over a super user session, although why the hell not? haha
alt-. (Alt-period) is a good shortcut to keep in mind. On first press, it inputs the last arg from the previous command. If you press alt-. again, it inputs the last arg from the previous-to-previous command. And so on.
172 comments
[ 4.7 ms ] story [ 224 ms ] threadNow title changed to "The Fuck...".
And yet the concept of the invocation `fuck --dry-run` is surely unappealing. :-)
$ apt-get install foo<return> $ fuck<return> -> sudo apt-get install foo<return>
zsh does something similar for history commands, I think:
$ echo foo foo $ echo !$<return> -> $ echo foo
It's basically a negative, aggressive emotional response, exactly a thing I'd rather not experience while working.
A failure due to not enough privileges might be a signal to rethink what you are doing; a mindless prepending of `sudo` is dangerous. Why not `su root` then?
Also, there was that screnshot of `sudo wget` as a response to a 403 error. This is exactly why you should re-examine a failed command instead of swearing around.
GNU find is smart enough to tell me that I've placed one of the flags or the find string in the wrong place, but not smart enough to correct the fucking error and do what I meant in the first place. (It knows, it just won't do it.)
"apt-get/yum install" is unusable by anyone but root. Why do I need to waste time re-keying the command? This is annoying enough that I've aliased it[1] on every machine I have access to.
I'd be willing to bet the collective man hours wasted on these worthless "you did it wrong, here's how you did it wrong, now go do it right" type messages, expands well into the decades.
[1]: https://github.com/Karunamon/dotfiles/blob/1174bbaee047107ea...
How often do you run apt-get install? I bet it's not even a daily routine. (If it is, you should have already automated it.) OTOH if you run chmod or chown and it suddenly requires root privileges, it's a good idea to think a bit; a disaster may be around the corner.
There are different mentalities; some crave for unconstrained aerobatics while others keep reminding to wear a parachute. I wish you all the luck, but I won't wish you be my SRE.
I think most of us have probably been at the point where we were typing something like "I hate you, you god damn computer!" into the terminal or text editor. I see this as a moderately elegant helper in those situations
That was my impression. It reminded me of little custom scripts or functions I've created that help with my day to day work, things I wouldn't necessarily give to someone because they were built with myself in mind. I know how they work and exactly what they do.
I like it, but I have to know every command it modifies/checks, I cannot run a blackbox command and hope.
And yep, it can add sudo to your previous rm -rf /.
Most actual instances of the actual word "fuck" aren't even swears.
Sounds like you need a review of: https://news.ycombinator.com/newsguidelines.html
Or perhaps just some common decency ? If you want a tool / platform to take off, using the word 'fuck' is not the way to go.
Also:
http://thefuckingweather.com/
http://www.whatthefuckshouldimakefordinner.com/
etc.
It's not a trivial question, though, and people aren't wrong to disagree. Cultural differences make for very different views here. In some (sub-)cultures swear words are uncivil and in others they are innocuous. There's no model that satisfies all these norms, so inevitably we have to disappoint some.
As a consequence of the above, we don't bowdlerize titles either.
Late night, vision is starting to blur and you've typed `git push origin master` incorrectly dozens of times already...
This was probably more of a misfired joke than anything ill-intentioned, but still, not ok to post here.
Far more easier to press CTRL-T than type `fuck` every time.
Vulgarity of expressions is not a function only of what the expression means, but of the acceptability of the expression itself in various social contexts. WTF is, generally, acceptable as not excessively vulgar in social contexts where expanding the last letter of the initialism into its referent would not be, but the reverse isn't true; WTF is pretty close, therefore, to strictly less vulgar.
This may not seem rational, but then the entire concept of vulgarity is irrational.
Which social contexts? Social contexts where people don't know what "WTF" expands to? It's not even a "minced oath".
"The f-word" is used exclusively by people being descriptive. Nobody says "So I was f-wording my spouse..." or stubs their toe and exclaims "oh f-word!". It is used when people are reporting what other people said. That is why it is considered less offensive; it is never properly used.
It signals to the easily offended, "I want to convey this information to you, but I am deliberately mangling words so that you know I too disapprove of the terrible word that was unfortunately used by somebody else."
"WTF" isn't used that way. When people say it, they are using it, not describing somebody's usage. There is zero implication of an apology or empathy with the audience's word-phobia.
Also was asked to install "suck." Not sure why / what that is.
Running 'Fuck' twice attempts to evaluate the previous 'Fuck'- and returns 'fsck' - which tries to forcefully check your mounted drive.
I wouldn't trust this app for practical use.
https://github.com/nvbn/thefuck/issues/1
Very useful though.
It is safe because it will autocomplete a command that you wrote before.
Another cool thing with it is that, it will list the commands that you can run after entering a word. It does this by reading the man page of the command you write.
brew <Tab> will list the brew commands for you to use with its explanations.
Looks like someone already has, actually: https://github.com/shaungallagher/thefudge
But seriously, I can't some up with a single situation where using "fudge/crap" instead of fuck would matter.
https://aur.archlinux.org/packages/thefuck-git/
^foo^bar
git brnch
^r^ra
This works on all Unix machines
You can also just run a sed style substitution in most shells, e.g. '$ !!:s/before/after/' or '$ !!:gs/x/y/', which is safer IMO.
Another nifty tool is vi editing mode. You run "set -o vi", and now your shell takes vi modal editing commands. That along with Ctrl-r for reverse history search has made life in the shell so much easier. Bash has a ton of little stuff like that built in. Zsh has a few more.
http://stackoverflow.com/questions/2600783/how-does-the-vim-...
Also, after you have entered a previous command, to edit it, or any previous command in the history, the first thing you have to do is press ESC (to go to command mode) and then k, thereby bring the last entered command into view for editing.
When editing a command, but in command mode (not insert/append mode), you can also press v to open the command in vi(m) in a temporary file, then have the full screen editor at your disposal to edit the command (useful for long scripts including for/while loops or long pipelines), and then when you save and exit (:wq or :x followed by Enter), the newly edited command gets executed by bash.
Also, this editing technique is useful not only for correcting typos in commands, but for modifying a previous correct command, to change some words in it and then re-issue it.
atom path/to/so[tab]/fi[tab] [return] git diff $_
Complete reference: https://www.gnu.org/software/bash/manual/html_node/Variable-...
See also: http://wiki.bash-hackers.org/syntax/shellvars
Preventing typo mistakes with bash autocomplete is even better than correcting mistakes afterwards, it also makes typing so much faster. It works with commands AND it also works for files inside the current working directory.
Hint: start typing your command and then hit TAB, voilà! Note: if there are more than 1 command/file option that starts with the same chars you wrote, hit TAB twice and you will have all the options displayed in front of you, it comes in handy to remember fast instead of browsing documentation.
Command example:
$ git rem[TAB] ---> $ git remote
$ git remote a[TAB] ---> $ git remote add
File example:
$ git add i[TAB] --> $ git add index.js
Multiple options example (TAB twice):
$ git r[TAB,TAB]
(will give you the options:)
rebase relink replace revert reflog remote request-pull rm release repack reset
The result is NO TYPOS! ;)
--------------------------
It would also be worth remembering the unix convention of using $ for regular user prompt and # for super user prompt.
In other words:
$ <--- if this is your prompt you're working on a regular user session.
# <--- if this is your prompt you're working on a super user session and you don't need sudo.
Again, that is just a convention, your OS/distro could be different.