Hello San Kumar! I looked at your source code, I was amazed that it was only one file, and only 100 lines of source code (less if we subtract whitespace). The less source code a program has while still maintaining functionality and being readable, the better. Which brings me to my next point, functionality.
You saw a problem, a big problem, which is that often even all of the features Unix has for help (man, apropos, etc.) are not sufficient to be able to quickly figure out how to complete a task, such that frequently people have to Google for answers, and why take the extra steps to go to a different window than the command line, search for answers, and return to the command line?
It's extra steps, but more importantly, it breaks "flow".
Also, this is one of the historic reasons that Unix lost the popularity battle with new/inexperienced users to Windows/Mac -- not enough user-friendly help, and this is especially true of Unix's historic command-line help systems.
So, I applaud the problem you chose to solve, and I applaud the elegant way in which you chose to solve it! You are a true Hacker (used in the positive definition, not the negative)!
So with respect to the problem you chose and the code that solves it, I say to you:
Well played Sir, Well played!
I vote that this code should become a standard part of all Unix distributions from now on.
Hi Peter. Thank you so much for your nice comment. It just made my day. I truly appreciate your kind words and it really wants me to make more of such things :)
Edit: I've added your comment to my project's readme file hoping that is okay to do so (let me know if not). Thanks
Came here to comment on how good this one was, thinking this was what the post was about. 10/10 work on this project, never ceases to amaze me and my coworkers.
No man. Never even heard of the other one until 20 hours ago.
Also as I replied to another comment this looks for programming related questions while mine is more general linux realted. Also both are free open source software with their source available so feel free to compare before accusing me of making a rip-off.
But, overall I'm quite happy with the response I got here, and I still really wanna make more of such things.
Sorry to accuse you without any evidence, sounds a bit aggressive in hindsight.
I just find it amazing that you created a very similar tool by the exact same name without realising it "howdoi". However I can understand it.
Funny story, my username "gitgud" was something I chose at random (I think git is good). Turns out there's a reasonably popular project called [1] gitgud, which I didn't event know existed! (so I can understand coincidental name collisions like "howdoi")
> But, overall I'm quite happy with the response I got here, and I still really wanna make more of such things.
I don't think that's fair - it uses the same name and idea, both of which are pretty obvious if you were going to write one yourself but is implemented in a different language and as more of a hack.
The author should tip the hat if it was inspired by the other, but "rip off" is unnecessary.
Having said that, I'm pleased to know about the python original (?), I will give it a whirl.
Instead of this, I keep a permanent log of every shell command I ever typed and have a handy alias to keep through it.
It also keeps track of the directory a command was run from, so I can limit my search. That way if I ever want to get back into a project I was working on long ago, I can just grep for commands run from that directory.
Not only that, but I can use it to cd to directories quickly. So if I was working under a huge p
10 level deep directory path, I have a alias that will match a string and cd into the last matching path in the permanent history file.
Not only that, but I can also search and then choose and rerun a command in the history, and also edit before rerunning it.
I have similar setup (infinite history, remember directory, shell session, ...), and then ctrl-r runs fzf that find the command first in this session, then in the same directory, then in the rest. I already hinted about that setup here:
Note, that just logging your directory, time and command in text file is great help, since if you don't remember something, you can just open the file and find what you need.
Made this quick little utility to help you when you forgot to do something in linux terminal, like:
- the arguments for extracting a bz2 file
- the command to reattach to a screen
- the latest ppa for a software program
- to something as simple as which linux distro / version i'm running
The concept is simple. Just download the script and now anytime from your terminal you can write
$ howdoi see my linux version
$ howdoi upgrade php
$ howdoi unzip a file
And it will search the internet and try to give you the most relevant search result so that you can do whatever it is you're doing without being interrupted
On OSX, the "StackExchange Search" workflow for Alfred is also fantastic for doing this.
Firstly, you can bind it to a hotkey, so don't have to type "how do i" before the query
Secondly, it updates the list of results as you type. Then you can select the one that seems to be the most relevant to open it in the browser (with a hotkey)
That's not the same use case. Man is good when you know the command to use but not how. Here the use case is when you know what you want to do but not how.
Man is a terrible tool for quickly remembering how to do something I do once in a while. The examples—usually the most important part—are usually at the very bottom, if they’re even there.
I use man all the time for exactly this. In fact it is something man really excels at.
The other nice thing about looking up options in the man pages is that you often see other useful options that you didn't know existed. I've found some of my favourite options this way!
You saw a problem, a big problem, which is that often even all of the features Unix has for help (man, apropos, etc.) are not sufficient to be able to quickly figure out how to complete a task, such that frequently people have to Google for answers, and why take the extra steps to go to a different window than the command line, search for answers, and return to the command line?
It's extra steps, but more importantly, it breaks "flow".
Also, this is one of the historic reasons that Unix lost the popularity battle with new/inexperienced users to Windows/Mac -- not enough user-friendly help, and this is especially true of Unix's historic command-line help systems.
So, I applaud the problem you chose to solve, and I applaud the elegant way in which you chose to solve it! You are a true Hacker (used in the positive definition, not the negative)!
So with respect to the problem you chose and the code that solves it, I say to you:
Well played Sir, Well played!
I vote that this code should become a standard part of all Unix distributions from now on.