Unified access to the best community-driven cheat sheets repositories | Hacker News Reader

Unified access to the best community-driven cheat sheets repositories

github.com

474 pointsghosthamlet83 comments

I like the idea, and think it has potential, but…

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 agree about the search engine.

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.

Dash absolutely has cheat sheets.

Holy cow! There's a whole category for them. How did I miss that?

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.

Similar project: Bro pages, like man pages but short examples of common use cases instead of extensive documentation.

http://bropages.org/

Thanks for the tip on that, bro! That will really come in handy.

I think tl;dr pages[0] might be more popular, on a similar topic

[0] https://github.com/tldr-pages/tldr

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.

Yes, writing it down.

you learn it by writing it down.

The act of writing down your own cheat sheet helps you to learn it.

It seems like the chain of four comments starting with Quequau's (https://news.ycombinator.com/item?id=17505892) and ending with superflyguy's (https://news.ycombinator.com/item?id=17507512) mean to disagree, but actually wind up agreeing. Is that correct, or is there some subtle distinction among them that I'm missing?

It's the nature of the medium being text-based.

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.

Mine was me observing the similarity of the previous two. If there was any difference there then it was too polite/subtle for me.

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.

I think the idea of a cheat sheet is that it isn't comprehensive documentation.

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.

You also need to have http://ohshitgit.com handy

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.

EDIT: https://github.com/chubin/cheat.sh/issues/32. I need to kick the habit of writing HN comments first, then bug reports later :).

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.

    curl cht.sh/find
    curl cht.sh/sed

Like these.

If you're wondering where this tool gets its data from, have a look:

https://github.com/chubin/cheat.sh#cheat-sheets-sources

There's also a cheat sheet built into nearly every computer - it's called man pages.

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.

It is good to have both.

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.

Sure, but some are very short, and others are very long and impenetrable. I like ones with examples. A better option is often "foo -h".

Also, the times a manpage contains examples seems like 1 in 20.

Especially in sections 2 and 3. Including examples would greatly increase their usefulness and I wonder why the authors don't do that.

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?

Similar project: http://tldr.sh

There’s also http://bropages.org

I use this all the time. It's very good.

It has clients in multiple languages, like

https://github.com/tldr-pages/tldr-python-client

The cheat sheet project also takes data from tldr.

https://explainshell.com is sort of a reverse

> 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.

https://github.com/chubin/cheat.sh

Is the dropdown at https://cht.sh/ a little sluggish in chrome for everybody?

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.

Do you know what's causing it?

The output seems to be optimized for people with dark background color on the xterm.

Is there a possibility to have a different color scheme?

Yes

curl cht.sh/:styles-demo

select the best style for you, and use it in the queries.

curl cht.sh/:help

for more info.

Also, use the special client cht.sh which supports persitent configuration and many other useful features.

Thanks, that helps.

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...

This is not working at all for me. I keep getting HTML & CSS vomit regardless on whether I use their command line tool or curl.

Weird. Did you file a bug?

    curl cht.sh
    curl cht.sh/apt-get

The above just works for me with curl.

post a

    curl -v cht.sh


?

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?

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.

Your curl user agent is most probably set to a browser user agent.

Try changing it to the curl user agent:

    curl -A "curl/7.37.0" cht.sh

Wow I love the idea. Will try it out today. Could be a time saving pal when switching to topics you are not working on every day.

How is it better than google

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.

Google is nice yes but you find different styled results and those results are normed and you know what to expect.

# 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

Would be cool to get offline functionality...

We are working on that but it is not so easy because many queries are generated just in time.

The high load problem is mitigated by the way, so you can try now if you want.

Most queries still don't work for me.

Weather wttr.in

Any way or how to self hosting ?

Would be nice to have an alfred or vscode plugin

getting a bit long for a cheetsheet

  curl cht.sh/js/foreach

It depends on topic + you can use the ~ notation to extract only parts of the cheat sheet. Check README on Github for that (or curl cht.sh/:help)

Works fine. Nice idea.

Not very respectful of https://github.com/chrisallenlane/cheat to use the same name.

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

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.

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.

Not sure why you're getting outraged about it?

tl;dr you're cheatin' bro!

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"

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.

The reasoning boils down to Google-ability.

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.

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

It's not just the title. Time of submission affects which parts of the world will be seeing the submission.

Also, randomness.

Don't forget the timing in regards to adjacent headlines in the feed at any moment a user reads it.

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.)

It's not just the title, I'm guessing people are more reluctant to click an unknown URL.

Your submission points at cht.sh while the current submission points at github.com.

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.

Reply on news.ycombinator.com