The search engine is not great. The tutorial gives the example of searching for "execute+external+program". Change "program" for "command", you're OK. Change "execute" for "run"and it bombs. For something that simple, this causes doubt that if I were to look for a solution to a problem in a language I was learning and it bombed, is the fault with cht.sh, or with me? Does the language even let you do that? I've have to run towards my browser to find out.
Also, the big advantage Dash has over this, and of course local generated docs (like Go's doc server et al), is that they are local. No network needed. I can be productive when offline, and when coding I often like to try and go offline. It's also faster, and for some docs I can even search a little with grep which I already remember. I can also get integrations with my editors, etc.
It's a great idea, I like it, and I think it has a niche, but it needs more synonyms in that search engine, and perhaps some integrations to make it a little more accessible to the workflow.
Using a commonly available bin like curl is great, but if codebase made me install something that would first run my query locally before hitting the net, that would be preferable. Because if I search for something, say ruby-related, then it's a good chance I'd search for something else later on that's ruby-related and having the command cache info locally would give me the same interface and quicker results later on.
I'm a big fan of Dash, but Dash is currently built around documentation rather than cheat sheets. If someone loaded up Dash with a bunch of cheat sheets, that would be really handy.
I enjoy cheat sheets as much as the next person but I think folks are missing out the key element that there's significant benefit in making them yourself.
FWIW, I didn't parse each of the nested comments as disagreeing, more like using their individual experiences to elucidate the point of the person they responded to.
Instead of investing in out of band resources like this, I really wish people would just contribute improvements to the upstream documentation, which is usually more comprehensive and up-to-date than any of these resources can be.
No, I don't agree. Git has great documentation but if you want to know how to use it you either spend 15 minutes reading the relevant part of the big free book or you Google for a cheat sheet. Same goes for vim. I don't know why but some people are satisfied with documentation which, although not incorrect, only makes sense when you already have a substantial understanding of the topic at hand.
Nonsense, you can also read the man pages, and if any of these resources are insufficient you should spend any time you would have spent writing a cheat sheet contributing improvements to the actual resources - the documentation is an open-source community project as much as the project itself is.
Sounds like a bit of a waste of time to me. What are the odds Linus is going to update the git documentation with my list of handy shortcuts? He'll just swear at me. I don't think the official documentation is the place for it; not now it's been written the way it has. I'm happy with the book + my notes on gitlab.
Well, for one, Linus isn't the current maintainer of Git. It's currently Junio C Hamano <gitster@pobox.com>, someone whose main responsibility in open source is looking after git, who has the time and inclination to review your contributions thoughtfully. Have you ever actually read a git man page? Or do you just get all of your git knowledge from scattered blog posts and cheat sheets? No wonder people think git is hard. Read a random git man page right now and you'll find it quite pleasant to read and containing a plethora of useful information.
I like it. I also like the feature 'Freak_NL pointed out - quick memory-jogging examples for a command.
Speaking of those top-level queries, I've noticed some of them are reported as unknown, even though they then are suggested. Observe:
temporal@galactica~> curl cht.sh/lisp
Unknown topic.
Do you mean one of these topics may be?
* lisp/ 100
* elisp/ 89
* alias 67
Changing the URL to cht.sh/alias correctly gives a list of examples, while lisp and elisp are always reported as unknown. My guess is, something somewhere is storing those tokens with forward slash in the name, whereas the HTTP handling code strips it out from request.
I like how this gives me access to succinct example usages of tools just enough to get me going or to jog my memory for how a certain tool works — without having to resort to using a browser and a search engine.
This is true but they are often long and complicated and aren't always conducive to quick solutions or refreshing memories of a useful combination of arguments.
That's true. However I often encounter co-workers refusing to read man pages, because they only want to see a cheat sheet. They end up endlessly wandering Stack overflow and google for hours instead of spending 5 minutes going through the actual manual.
those are hard to be considered cheat sheets... extensive reference documentation, maybe, but "command --help" is more similar to a cheat sheet than "man command"
I like this (I find brief documentation with worked examples makes it a lot easier for me to understand most things), but I've just had a look at the python lambda one which is served up by curl... and it has some errors in it. Followed the instructions on how to edit it, forked it, and... the version I went to edit has the two changes I thought needed doing already done (3 hours ago)! Pity, my first chance to contribute to a project (early-learning level python student in my mid 40s)!
It does beg the question when do the curl versions get updated?
> Instead of creating yet another mediocre cheat sheet repository, we are concentrating our efforts on creation of a unified mechanism to access selected existing well developed and good maintained cheat sheet repositories covering topics of our interest: programming and operating systems usage.
Yes, it is not good, we are working on the new frontend.
I can give a link to it to you if you want, but not here, because it will not handle the load that comes after that; just write me a mail if you want to test it.
Everybody who reads this and what to help testing the new frontend write an email to me I will share the link with you.
Wait, in stealth mode it's listening for any text selected, even in other programs? This is a bit mind boggling - what's to prevent any program listening to any other (like a password manager for example)? Is this sort of access not prevented by an accessibility permission?
This is how traditional desktop operating systems work... some things require admin rights but most stuff is indeed fully accessible to any application.
This cleverly one-ups http://bropages.org/ by leveraging an existing command in the environment you are most likely to type "bro curl", but you don't need to install a tool first.
I give it five minutes before this is on all the plagiarism checker of all those "coding challenge" sites recruiters/HR love to throw out in pre-interview screening...
What user agent string is your curl request sending out?
I think it does user agent checking to decide whether to send out a shell escaped version of the page or one with traditional web markup because when I make a HTTP request with one of my other CLI HTTP clients it only sends shell output if I send curl's UA.
Which curl version do you have? Might it be a chance that you have a curl script somewhere in your PATH before real curl which enforces some user-agent setting?
# Sorry, we are experiencing extremely highload now.
# We are working on the problem and how to get it fixed soon.
# Please come back in several hours or try some other queries
Can you quickly find cheat sheets in a similar style to one another via google? Some people prefer to stay in their commandline as much as possible, too.
We are of course aware of the beautiful cheat project and we even use it (what is documented in our README.md file), but please keep in mind that:
1. Our project is called cheat.sh and not cheat (for example xterm.js and xterm are two separated projects and xterm existed for decades before xterm.js; should they be renamed too from your point of view?);
2. We are trying to mitigate the impact by using cht.sh where possible;
3. We do not and did not ever use the name to steal, to borrow, or to somehow use popularity of cheat.
I do not see any naming conflict actually. The client/command is called cht.sh, does not even have cheat in their name.
I am a big fan of the cheat project myself, and I don't want to do any harm for it. Even more, as I said, I would prefer that we cooperate with that project.
sh is not a distinct enough term when googling for shell suggestions, because both cheat and cheat.sh will have sh in the results. That is very distinct from xterm.js where xterm-only results are very unlikely to have JS in them.
Cheatsheet is a term of art, not something unique.
The word has been in common usage in programming for literally decades before Chris wrote his program. People used to pin them up in their cubicles before the internet existed.
How is a similar (not even identical) name a “name conflict”? Even if both were named “cheat”, one is a Unix command, the other is a URL that you access via HTTP (in other words, they occupy different, non-conflicting namespace). What’s more, “cheat” is a fairly natural name for a cheat sheet. In sum, I don’t understand what issue you have with the naming.
I often wonder how much time people invest in the following before going off on their own:
1. Finding similar open source projects to what they want to exist
2. Digging into the project to see how close it is to what they want
3. Attempting to contribute to bend it to fit their needs
How much of these "really similar project" situations are "I want the project to be mine for marketing / brand / control reasons" vs "I didn't know this existed already"
It is interesting to see how the title effect number of upvotes and comments. I’ve submitted this other day and it did not get any upvotes. My submission: https://news.ycombinator.com/item?id=17471476
Yes it’s called “marketing” and it has a huge impact on initial perception.
Consider each of these and think of which would catch your eye enough to click it, read about it, then come back and upvote it:
* Meta cheatsheet
* The only cheat sheet you need
* Cheatsheet.sh
* Cheat Sheetah
* Unified CLI Cheetsheet
People gaming the title is the reason for the rule that the title has to match the actual linked article. Though if you’re the creator of the content that’s not an issue as you can title it at the source however you want.
Also that "Meta cheatsheet" sounds like a cheatsheet for something called "Meta", and not being familiar with any such technology, I wouldn't be curious about a cheatsheet.
Unless something has changed in the repo, the Github description -- as close to a "headline" that a Github repo can get -- is: "the only cheat sheet you need"
I agree that "Meta cheatsheet" is not a very effective title. When the repo doesn't have a Github description, I usually go with:
[repo name] - [first line of README.md]
In this case:
cheat.sh - Unified access to community-driven cheat sheets repo of the world.
(I modified it to abbreviate "repositories" to "repo" and to omitted the phrase "the best", to go along with HN's rule for avoiding sensationalism.)
I think there are a few variables, like time of day and competing headlines. I saw some breakdowns of the concept on reddit a while back, it's seemingly pretty random.
The search engine is not great. The tutorial gives the example of searching for "execute+external+program". Change "program" for "command", you're OK. Change "execute" for "run"and it bombs. For something that simple, this causes doubt that if I were to look for a solution to a problem in a language I was learning and it bombed, is the fault with cht.sh, or with me? Does the language even let you do that? I've have to run towards my browser to find out.
Also, the big advantage Dash has over this, and of course local generated docs (like Go's doc server et al), is that they are local. No network needed. I can be productive when offline, and when coding I often like to try and go offline. It's also faster, and for some docs I can even search a little with grep which I already remember. I can also get integrations with my editors, etc.
It's a great idea, I like it, and I think it has a niche, but it needs more synonyms in that search engine, and perhaps some integrations to make it a little more accessible to the workflow.