[kissgyorgy]

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.

[AdieuToLogic]

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

0 - https://forums.freebsd.org/threads/howto-create-a-manpage-fr...

1 - https://www.freebsd.org/cgi/man.cgi?query=man&apropos=0&sekt...

2 - https://spin.atomicobject.com/2015/05/06/man-pages-in-markdo...

3 - https://pandoc.org/MANUAL.html

[nessunodoro]

to these great refs I would recommend the Ruby tool ronn

https://github.com/rtomayko/ronn

[crispyambulance]

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

[rmetzler]

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.

[kissgyorgy]

The perfect tool for your problem is https://tldr.sh/.

You don't even have to write the pages yourself, there are a lot of already pre-written.

[alanbernstein]

Great! Now, how does that bash syntax go again...?

This is why I have a similar tool for command line cheat sheet snippets - recalling bits of syntax to be combined into a command or a script.

[grenoire]

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.

[alanbernstein]

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.

[alexryndin]

And then rofi for great good!