Once I tried a tool like this, but just realized, there is already a method of that: the ~/bin folder.
You can write bash scripts, or scripts in any programming language with the proper shebang line, you can download other people's scripts, and you don't need bash history to keep them. Listing all of them is just an ls. I tend to not put file extensions of them and use good naming, so you can see everything without looking into them.
> Once I tried a tool like this, but just realized, there is already a method of that: the ~/bin folder.
One thing I'd add to this is that "crib notes" can be captured in man[0] pages. For example, having them in $HOME/man and ensuring MANPATH[1] includes it serves as a nice complement IMHO. There seems to be a markdown-based tool[2] which can assist in authoring them too.
EDIT: It looks like pandoc[3] can generate man pages from markdown as well.
> ... there is already a method of that: the ~/bin folder.
More power to you if you can do that, but for me it's a memory problem and a problem of being able to figure out WTF options I need when I am in the middle of something.
man pages (and --help) are great if you have the time to sit down, ponder and experiment. But when you're trying to get stuff overwith, a massive wall of historically interesting text just isn't helpful.
The vast majority of invocations of any given command, I suspect, are limited to a not more than a handful of use-cases. In other words just enough combinations of arguments and options to perform a small number of different tasks. This is what people are typically interested in when they're on the command line. In that context getting massive dump of every possible option in a man page is frustrating and counter-productive.
For example, "tar". I use this command in 2 simple ways: archive a directory into a gzipped tar or extract a gzipped tar. This is what effectively everyone uses it for >99% of the time: toggle between a directory and a tar.gz file.
Basically... just 2 forms "tar -zxvf" and "tar ..." oh shit, I forgot how to tar/compress a directory, let's check the man page... ok "tar -cf" to create a tar, but wait I want it gzipped, and actually I forgot what the z, v and f stand for, now I need look each of those up, wait, do I really mean gzip? or bzip, oops more research.
To be fair, tar might be too easy an example but you can easily go down a manpage-rabbit-hole because of a lack of common usage examples.
I think it’s just a habit to turn these two or four versions of using tar into the same amount of one liner shell scripts. Or maybe a longer one with options and usage printing.
As GP, mentioned, you put the correct shebang. I write stuff in Python and make them as pipe-capable as possible. You don't have to bend hell and flip it upside down to write scripts.
Sure - I use both bash and python for this purpose. Sometimes bash really is the right tool for the job, for example, when you need to use a lot of other complex CLI utilities, or when pipelines of simple commands get the job done in a simpler way.
I'm just explaining why a command line cheat sheet tool is useful to me. I don't need to be convinced that it isn't.
Wow, this is really cool. I assumed this was going to be written in go or rust, but taking a look it's actually all bash! I'm always surprised by how much people can get out of bash.
It's also some of the cleanest bash I've seen. Definitely going to be using some of these patterns for my own scripts.
This looks cool, a common workflow of mine is `cmd --blah --blah ` ah damn I don't know the value for blah, okay, fzf ` --blah=(blahgen | fzf) ` oh I'm also missing [...]
This seems like it can help do the same thing more quickly, so I'm keen to give it a go.
I do like shell history though, a shame to just have a bunch of `navi` entries - I wonder if it could be faked; populated with the chosen command afterwards?
navi allows you to browse through cheatsheets (that you may write yourself or download from maintainers) and execute commands, prompting for argument values.
Looks neat. I wish, though, there was a way to try it out in the browser as advertised without having to sign up or login. Might be a requirement of the site hosting the demo but whoever it is, forcing login is always and forever a deal breaker for me.
Looks like a really useful tool. Another tool I use like this is bropages or the `bro` command(1) which gives many examples similar to this for any command like ls, docker, etc. Sometimes it's useful when you don't have time to read the entire man page.
I don't like the fact that an unknown command is executed before i can see/inspect what it is. Currently you won't even see what command was executed afterwards, you only see the result...
Would be nice to be able to also show the command below the item/result.
--print is possible, but it's cumbersome and not interactive: you can't "accept" the command after inspecting, and execute it.
Is there a key command or way to find out what's below the cheat? For instance, I tried the "local ip address" example in the demo and it gave the IP address but now 'how' -- ifconfig? was it in a text file? env var? script?
This is pretty cool! It’s great to see that lots of tools are trying to make the command line less intimidating, and adopting more friendly methods than the man pages.
About the cheatsheets itself, it might be great to share the cheatsheets with a project sharing somewhat similar goals, tldr.sh[0] (which focuses less on interactivity but more on completeness and practicality).
I’m more than excited to see the shell being more approachable. I have introduced the shell to quite a lot of my non-programmer friends with package managers and bulk renaming, but they don’t use the shell enough to memorize all of the commands. These efforts lower the barrier to use the shell... hence making the demonstration of the command line’s powers more easy.
oh this is really cool, thanks for sharing. i also really appreciate that you have links to other projects that offer similar features so people can contrast and compare and find what works best for them.
Not sure what you mean, the shebang line is bash, so you need bash installed, but invoking it from zsh shouldn't cause a problem any more than invoking anything else could.
If you meant 'why is the shebang line bash, isn't it POSIX compliant' - I don't know.
Looks nice though. Not sure I fully understand how the chaining/'prompts you for arguments' works (from UX perspective) but keen to give it a go.
You can write bash scripts, or scripts in any programming language with the proper shebang line, you can download other people's scripts, and you don't need bash history to keep them. Listing all of them is just an ls. I tend to not put file extensions of them and use good naming, so you can see everything without looking into them.