An interactive cheatsheet tool for the command-line
github.com
github.com
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.
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...
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.
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.
> ... 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.
You don't even have to write the pages yourself, there are a lot of already pre-written.
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 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?
Combining both cheatsheets and a better UX is brilliant. Wish I had this years ago when trying to wrap my head around the shell.
I really like this implementation!
(1) https://www.ostechnix.com/3-good-alternatives-man-pages-ever...
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.
I hope you like it!
https://github.com/denisidoro/navi/blob/master/cheats/networ...
I'd nitpick on the implementation, but the point is you can change it. :)
ip -o a sh up primary scope globalAlternatively, you can use the --print option
I hope you like it!
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.
[0] https://tldr.sh
My only concern is that this way it would be impossible to add subcommands to navi
Let's say that in the future I want to add a command for removing a cheat (navi remove)
The way you described, it would look for snippets which contain "remove"
Any ideas?
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.