The Linux cheat command(opensource.com)
opensource.com
The Linux cheat command
https://opensource.com/article/22/6/linux-cheat-command
78 comments
Thanks for coding! How does your https://github.com/cheat compare to https://github.com/chubin/cheat.sh ?
Is it available via brew?
It is! There's a wonderful community-maintained `brew` package for it:
`brew install cheat`
`brew install cheat`
oh man, could you do this for powershell as well? :-P
`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 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.
As I don't need it that often, I prefer the zero-install `curl cht.sh/tar`.
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
Man pages for the lazy.
Man pages for the lazy.
But sh... sorry "cheat" is easier to remember, maybe.
It's too bad most man pages don't include anything in the EXAMPLES section.
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.
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.
My biggest pet peeve! I have a feeling that in the past, man pages used to be much more detailed when it comes to actual examples.
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
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
Have you ever needed to briwyw the gomleqq on Linux? We at Digital Ocean sure have. But how do you do it? Read on to find out.
I think you won the Internet for the day.
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?
No, it is Linear A.
Remember the Klingon saying.
> A programmer who releases open source lacking a man page and info file has no honor.
Remember the Klingon saying.
> A programmer who releases open source lacking a man page and info file has no honor.
To paraphrase: Eh, you were lucky to have a page! We used to have to skip forwards and backwards through a video!
As a Unix user since around 1980 I can reassure you that man pages these days are far more extensive than they used to be.
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
ls -1AacCdeFilnpLRrSsTtuvwxXhk FILE... indeed
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
ls -1AacCdeFilnpLRrSsTtuvwxXhk FILE... indeed
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.
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.
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 was emacs trying to be a web-browser and it can go die in a fire.
I hated the days of "the man page is blank, see the GNU info documentation" - almost drove me to BSD.
I hated the days of "the man page is blank, see the GNU info documentation" - almost drove me to BSD.
They're both suited to their individual purposes.
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.
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.
In a recent discussion of fzf, I looked through the man page and still didn't know what it was supposed to do. An example might have helped.
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.
A useful, related website: https://explainshell.com/
cheat[1] https://github.com/cheat/cheat
What are you talking about? It's a Golang program for Linux/Unix
https://github.com/cheat/cheat/blob/master/cmd/cheat/main.go
https://github.com/cheat/cheat/blob/master/cmd/cheat/main.go
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]
[1] https://en.wikipedia.org/wiki/Single_UNIX_Specification
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]
[1] https://en.wikipedia.org/wiki/Single_UNIX_Specification
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.
> No. That’s idiotic reasoning.
…
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.
> No. That’s idiotic reasoning.
…
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.
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.
It's not Linux...It's GNU/Linux...
Could not resist.
Could not resist.
I agree. Almost nothing is Linux and nearly everything is GNU.
Is there a compelling reason to choose this over tldr?
I'd ask the same question in the other direction, it just happens I use tldr already.
I'd ask the same question in the other direction, it just happens I use tldr already.
I'm the author of `cheat`.
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.
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 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!
Awesome. I was going to ask the same thing, but this answers everything that I was going to ask. Thanks!
If I ever have an interview on a Linux system I'm going to ask the interviewer if I'm allowed to cheat.
At least that's how I plan to get myself to remember this command.
At least that's how I plan to get myself to remember this command.
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?
Zsh is a superset of Bash. There's little-to-no learning curve from switching, if you just stick with Bash syntax, and many advantages.
Here is a good overview on Zsh vs. Bash [0].
My favorite Zsh feature is the plugin ecosystem [3]. Oh My Zsh [1] and Starship [2] are awesome.
[0]: https://apple.stackexchange.com/questions/361870/what-are-th...
[1]: https://ohmyz.sh/
[2]: https://starship.rs/
[3]: https://github.com/unixorn/awesome-zsh-plugins
Here is a good overview on Zsh vs. Bash [0].
My favorite Zsh feature is the plugin ecosystem [3]. Oh My Zsh [1] and Starship [2] are awesome.
[0]: https://apple.stackexchange.com/questions/361870/what-are-th...
[1]: https://ohmyz.sh/
[2]: https://starship.rs/
[3]: https://github.com/unixorn/awesome-zsh-plugins
> Zsh is a superset of Bash.
zsh is not a strict superset of bash; I have aliases that I still haven't figured out how to port
zsh is not a strict superset of bash; I have aliases that I still haven't figured out how to port
I had a script that worked fine in BASH but errored in Zsh. It had to do with arrays and I don't remember the problem.
It was probably that in zsh, arrays start at 1.
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.
I like zsh.
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.
I like zsh.
Most bash scripts work fine in zsh. I recommend you switch because your learning curve will be very shallow.
Here's a gist (i.e. no ads) that I wrote to guide people new to zsh through some of the many options available: https://gist.github.com/aclarknexient/0ffcb98aa262c585c49d4b...
Here's a stack exchange post about the differences between zsh and bash: https://apple.stackexchange.com/questions/361870/what-are-th...
Here's a gist (i.e. no ads) that I wrote to guide people new to zsh through some of the many options available: https://gist.github.com/aclarknexient/0ffcb98aa262c585c49d4b...
Here's a stack exchange post about the differences between zsh and bash: https://apple.stackexchange.com/questions/361870/what-are-th...
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.
macOS ships with zsh and it was easier to switch all the linux boxes to zsh than to fight homebrew into giving me a relatively recent version of bash.
So far I've no complaints and oh-my-zsh is nice.
But I can't really point to something and say "oh I'd die without this zsh feature".
So far I've no complaints and oh-my-zsh is nice.
But I can't really point to something and say "oh I'd die without this zsh feature".
I feel that man pages should add a TLDR section after NAME and restrict the bottom EXAMPLES section to more elaborate / less common examples.
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.
check out tealdeer, it's a rust implementation of tldr but improves speed (on my machine at least) drastically!
https://github.com/dbrgn/tealdeer
https://github.com/dbrgn/tealdeer
The page didn't mention it but there is one that can be installed via brew as well.
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.
Available via port too, with the option to download the community cheatsheets.
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.
Another similar command is the "bro" gem, which provides user sourced and voted examples
http://bropages.org/
http://bropages.org/
Unfortunately this is unmaintained
Nice!
p.s. Arch Linux is `yay cheat-bin` NOT `yay cheat` (source compile).
p.s. Arch Linux is `yay cheat-bin` NOT `yay cheat` (source compile).
Thanks for making this. It is a very handy tool!
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 :)
[deleted]
tldr is already available and cheat looks like a fork of it.
check it out: sudo apt install tldr
imagine that!
check it out: sudo apt install tldr
imagine that!
`cheat` is not a fork of `tldr` (I'm the author of `cheat`), though the latter is a lovely tool.
man -k somestring
Why do you need this instead of publishing man supplements that append to man files?
cheat: command not found
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
(I also tried on MacOS, but that is not Linux)
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
(I also tried on MacOS, but that is not Linux)
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”).
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.
Also, BSD is not Linux.
> 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.
Also, BSD is not Linux.
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.
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'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 :)
> involves me running `make` on my local machine and dragging-and-dropping binaries into the Github UI. It's embarassing.
don't hate the player, hate the game. a lot of folks do this and it is okay.
don't hate the player, hate the game. a lot of folks do this and it is okay.
Arch has it in the AUR with `yay cheat-bin`. Pow, done!
I'm actually the author of the `cheat` tool. Feel free to ask me if you have any questions about it.