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.
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.
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.
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
Do you mean one of these topics may be?
* lisp/ 100
* elisp/ 89
* alias 67
EDIT: https://github.com/chubin/cheat.sh/issues/32. I need to kick the habit of writing HN comments first, then bug reports later :).
It does beg the question when do the curl versions get updated?
It is good to have both.
It has clients in multiple languages, like
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.
Is there a possibility to have a different color scheme?
select the best style for you, and use it in the queries.
for more info.
Also, use the special client cht.sh which supports persitent configuration and many other useful features.
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.
Try changing it to the curl user agent:
curl -A "curl/7.37.0" cht.sh
curl -v cht.sh
Would be cool to get offline functionality...
The high load problem is mitigated by the way, so you can try now if you want.
The original cheat does exactly the same thing, has a big following and more stars, and has existed for years.
I've opened an issue re: the name conflict https://github.com/chubin/cheat.sh/issues/34
Afaik these are the big players in the space:
- bro: https://github.com/hubsmoke/bro
- tldr: https://github.com/tldr-pages/tldr
- cheat: https://github.com/chrisallenlane/cheat
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.
A similar debate played out when the gofish package manager was launched, which conflicted with the fish shell https://github.com/fishworks/gofish/issues/37
Anyway, the choice is not mine to make, it just seems like an easy issue that could have been avoided by choosing a name that wasn't already in use.
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.
Not sure why you're getting outraged about it?
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"
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
* 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.
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]
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.)
Your submission points at cht.sh while the current submission points at github.com.