`cheat` allows you to create cheatsheets on your local machine, so you can trivially create whichever Powershell cheatsheets you need.
I don't believe we have any Powershell cheatsheets in the upstream community repo yet, but if you create some, please share them! They would surely be appreciated.
I use this fairly regularly! If you don't know, you can type almost any command, e.g. `curl cht.sh/ls` and it shows you common usages of `ls` with a short description for each command
This was essentially my primary motivation for writing `cheat`. The `man` pages are thorough, but often lack examples demonstrating the common use-cases.
I eventually tired of Googling "how to extract a tarball" (because I'm too lazy to read the lengthy manpage), and decided to create some supplemental tooling.
The feeling that a single actual example would make the whole thing a million times clearer.
Sometimes there's also an `info` file with more detail.
And one of my pet peeves. Do a search "How to briwyw the gomleqq" and the first one you look at has screen after screen of how to install Linux and everything and then finally at the very bottom it is finally revealed
gomleqq --briwyw 40 --eiei-dddd 9
and that's the little bit of knowledge that I needed all along, along with that fact that 40 needs to be at least 4 times bigger than 9 or you'll get dropped packets.
going back and forth from a search tab, the results, and this comment, I'm over here trying to remember FAST in case Im having a stroke or what. Is this tool written in Klingon or something?
The extensivisity is part of the problem - you don't want paragraphs upon paragraphs, you often just want a short reminder as to which option is which.
But so many programs have decent built in "help" now it's not as big a deal - I remember when ls --help would just return every possible valid option on one big line ... which now Google does for us: https://www.google.com/search?q=ls+options
My impression is that people stopped filling their man pages because the information got into info pages when there was an ongoing campaign to create those (because the format was much more expressible).
And then, the users simply didn't learn how to use info, so developers dropped those and kept only the very short man pages.
The Info command kind of sucks to use though. It's way more complex than you would expect for a manual viewer. The help screen itself is 300 lines long and full of stuff like:
LFD (select-reference-this-line) Select reference or menu item appearing on this line
The help page talks a ton about xrefs and nodes and references and echo areas and tree searches without ever explaining what any of those things are. The h key as always does nothing.
Info pages are like big old clunky manuals with diagrams and schematics and "theory of operation" chapters. Great when you're on the ground doing maintenance.
Man pages are like quick reference handbooks. Great when you're already at 30,000' and just need to keep the plane flying.
That kinda makes me think if it would be possible to write a tool that patches these cheat sheets into man pages that don't yet have an EXAMPLES section.
Oh, my mistake. I see the program code is written in Linux Go, a programming language for Linux. Right?
No. That's idiotic reasoning. Go is not a Linux programming language no more than C++ or Javascript is. Even if Go was developed on Linux, it still just a programming language; it is not owned by Linux nor is it in kernel space, and it runs on DragonFly BSD, FreeBSD, macOS, NetBSD, OpenBSD, Plan 9, Solaris, and Windows. Why isn't it instead a Windows command? Because no one else does this. No one says, "a BSD command" or what have you. Shell commands run in the shell. Shells run on everything.
Why does everything Linux touches become described as Linux something?
That is what I am talking about, Linux entitlement: if Linux runs it, it is a Linux thing, regardless of whether it was developed 30 years before Linux existed or whether it was ported to every other OS previously or subsequently.
> It's a Golang program for Linux/Unix
Anyway, thanks for making my point. Unless you mean that Linux is UNIX, in which case there are some deeper issues here.[1]
How charming. Everybody loves having their language use corrected sarcastically.
But you should really read up on your English modifiers next time, because your point is based on a common vulgar-linguistic misconception. “Linux,” in this case, is plainly being used qualifyingly rather than classifyingly. It’s subsective, but ambiguous as to whether or not it’s intersective - but I think the answer to this is quite clear. Say we had to reformulate the noun phrase into a clause. Would we really come up with e.g. “The `cheat` command is Linux-specific” as the equivalent intended meaning? Or would it more likely be “The `cheat` command works on Linux”? The point is that the `cheat` command can be used in a Linux shell, not what scripting language it’s written in.
> Accuracy is not pedantic
This is the wrong attitude, my dude. Wrong, wrong, wrong. It’s probably intended to be light-hearted because it’s self-referential and self-contradictory (pragmatically, not semantically, as ironic humor does), but it’s still too close for comfort in this context. I know computer dudes who are like this for real. One graybeard almost had me saying fuck this when I was still starting out.
Looks to me like it's being used to exclude. If it is described as a Linux something, it is not anything other than.
The language mistakes are being made constantly by those that only see or are aware of Linux. I want to call it the Linux hole, because anyone who is OS agnostic is never in that hole from which only Linux can be seen or talked about as though it were distinct and isolated from other similar OS, from which Linux was developed, not the other way around.
First of all, `tldr` is a lovely project, and if it's working for you, you should continue to use it.
If there's distinction to draw between the two projects, it's that `tldr` (to my understanding) is primarily a client for serving cheatsheets that are maintained in the upstream Github repository.
By contrast, `cheat` is focused around allowing users to create their own cheatsheets (stored perhaps only on their local filesystem), and is useful for storing cheatsheets in which others may have no interest.
`cheat` also allows you to sort and search these cheatsheets (which are just markdown files) by "cheatpaths", which are named directories in which cheatsheets may be stored. Cheatpaths have specificity rules that are configurable, such that cheatsheets on local cheatpaths may be preferred above those on global cheatpaths.
As a personal example, I run 3 cheatpaths:
- the community cheatsheets (contained on Github)
- personal edits I've made to the above
- cheatsheets for my dayjob
So, as an example, the community `ssh` cheatsheet is on the global cheatpath, and should contain the cheats that everyone should care about.
My personal `ssh` cheatsheet will contain edits I've made to that cheatsheet. Here, I'll store little tricks/tips/whatever relevant to my personal workflow that are useful to me, but will not be useful to others.
The dayjob cheatpath contains cheatsheets regarding how to do various tasks pertaining to my dayjob. How to start an app, or restart the CI server, or whatever.
Another example: I recently moved. I have an `address` cheatsheet that displays my new address, which I have yet to memorize.
So, `cheat` is perhaps better if you're interested in taking personal notes like this, whether of a technical or non-technical nature.
If you're primarily interested in community cheatsheets, you should keep using `tldr`! It's a wonderful project.
Glad I asked! The article (I can see you didn't write it) feels like it comes from a parallel world where tldr is called 'cheat' and is a standard POSIX command, it has maybe a paragraph right at the end about custom sheets.
I probably wouldn't use the extra features just because I use a password vault for that kind of thing, since a subset of those are, say, a new debit PIN and I need all that kind of thing to be in one place.
If I did more sysadmin stuff I could see that being handy, annotating various incantations would pay off over time, aliases have a way of slipping through the cracks. Thanks!
I personally have been using tldr for a while now and love it. It works similarly to cheat, but I see in researching about the project there are others as well. I also use zsh-autosuggestions and zsh-autocomplete so it really makes things easier.
Unrelated but I'm wondering. Should I switch from bash to zsh, if so, why? It's taken me quite a while to get up to speed with bash, especially scripting. How steep is the learning curve?
I'll take this chance to shill for Fish. For interactive use it is a joy to use, with better defaults w.r.t. auto completion and history. Not much learning curve if most of the time you're just entering commands and pressing tab or arrow keys. I still use Posix Shell for scripts though, because it's installed everywhere.
I'm going to go against the grain a little and disagree with a lot of the comments.
My suggestion is to use the same environment in development that you use in production.
If you are running zsh on your servers then run zsh on your workstation.
I run a mix of Linux, FreeBSD, and OpenBSD servers in production; and have found that 99% of the time it didn't matter.
I had been using zsh on my workstation and about 25% of my server fleet. The others were either too old, didn't support it, or whatever.
Of those 75% of servers (over 500 boxes) a small handful encountered occasional problems when running my 'written on ZSH script'; that didn't happen when I re-wrote/tested the script on bash.
We are talking about ~4 errors over the course of a year-and-a-half or so.
It was more annoying then anything else; and nothing broke as a result of it. I just had to manually go do the work that my script was suppose to do.
Definitely switch to zsh for interactive use, the differences are minimal enough it will not take any effort to switch. Even forgetting everything else just the superior tab complete is enough to make it worthwhile. Still use bash for scripts they will be more portable.
That seems like an unnecessary complication; just put the more simple examples at the top of the section and make them more complex as you proceed down.
Playing around with it a bit, looks like you need to install some configs after but works as described in the article. Will definitely be helpful for those like me who are trying to expand their command line prowess.
One of the better parts of kubectl's documentation is that there's generally examples like this, so you can get the more common examples in the help and copy/paste/lightly modify, as needed.
I didn't link the article, but it's my pleasure. `cheat` was first and foremost a "scratch your own itch" tool. I'm very happy to see that others are finding it useful as well :)
Out of the box, I dont have an OS (or shell) that ships this. I wouldnt call it so much a command, which implies it is inherent to the system, I'd say its a tool, like a step below coreutils in that its not so pervasive.
Arch didnt have it, Debian rolling or stable didnt either, neither does RHEL
Sorry, but that’s kind of a made up definition of “command”. By that definition, gzip is a command on “most” systems, bzip2 on “a lot”, and xz on “some”. And yet they are all entered on the command line.
And what tools a particular system comes with is pretty much arbitrary. The otherwise ubiquitous curl for example is not part of, e.g., coreutils (which is a rather Linux-specific thing, the BSDs have most of the stuff in there as part of their “base”).
> Sorry, but that’s kind of a made up definition of “command”. By that definition, gzip is a command on “most” systems, bzip2 on “a lot”, and xz on “some”. And yet they are all entered on the command line.
> And what tools a particular system comes with is pretty much arbitrary. The otherwise ubiquitous curl for example is not part of, e.g., coreutils (which is a rather Linux-specific thing, the BSDs have most of the stuff in there as part of their “base”).
"I wouldn't call it"...
I might be encouraged to give context for my subjective opinion. If youd rather make fun of my perceived ignorance, thats also your prerogative.
If it is not in the repos it isn't going to be used.
Step 1 in getting adoption on the Linux side is making "apt install cheat" and "dnf install cheat" work. Plus whatever the current preferred Mac package manager is.
I'm the author of `cheat`. Regrettably, I agree with you regarding the lack of `apt` packaging as a major barrier to adoption.
I've looked into creating it previously, but found it to be non-trivial. Like a lot of FOSS maintainers, I'm pretty strapped for time these days, and I simply haven't gotten around to it yet.
The next round of work I want to do on this project is to improve the CI pipeline. My dayjob these days largely involves configuring CI pipelines, and yet the `cheat` workflow for the time being involves me running `make` on my local machine and dragging-and-dropping binaries into the Github UI. It's embarassing.
Once I get the CI squared away, I'll take a look at `apt` packaging.
Seeing this project on Hacker News has given me renewed motivation, however. Perhaps I can free up some time this weekend :)
I'm actually the author of the `cheat` tool. Feel free to ask me if you have any questions about it.