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.
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.
[+] [-] kissgyorgy|6 years ago|reply
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|6 years ago|reply
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
[+] [-] crispyambulance|6 years ago|reply
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.
[+] [-] alanbernstein|6 years ago|reply
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.
[+] [-] alexryndin|6 years ago|reply
[+] [-] imposterr|6 years ago|reply
It's also some of the cleanest bash I've seen. Definitely going to be using some of these patterns for my own scripts.
[+] [-] dnsfr|6 years ago|reply
[+] [-] submeta|6 years ago|reply
[+] [-] OJFord|6 years ago|reply
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?
[+] [-] dnsfr|6 years ago|reply
[+] [-] rmetzler|6 years ago|reply
[+] [-] dnsfr|6 years ago|reply
[+] [-] blondin|6 years ago|reply
[+] [-] lapnitnelav|6 years ago|reply
Combining both cheatsheets and a better UX is brilliant. Wish I had this years ago when trying to wrap my head around the shell.
[+] [-] obituary_latte|6 years ago|reply
[+] [-] dnsfr|6 years ago|reply
[+] [-] faizshah|6 years ago|reply
I really like this implementation!
[+] [-] anchpop|6 years ago|reply
[+] [-] dnsfr|6 years ago|reply
[+] [-] superasn|6 years ago|reply
(1) https://www.ostechnix.com/3-good-alternatives-man-pages-ever...
[+] [-] DavideNL|6 years ago|reply
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.
[+] [-] dnsfr|6 years ago|reply
I hope you like it!
[+] [-] acoustep|6 years ago|reply
[+] [-] oyebenny|6 years ago|reply
[+] [-] davidjhall|6 years ago|reply
[+] [-] mikelward|6 years ago|reply
https://github.com/denisidoro/navi/blob/master/cheats/networ...
I'd nitpick on the implementation, but the point is you can change it. :)
[+] [-] dnsfr|6 years ago|reply
Alternatively, you can use the --print option
I hope you like it!
[+] [-] callmeschroeder|6 years ago|reply
[+] [-] dnsfr|6 years ago|reply
[+] [-] goranmoomin|6 years ago|reply
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
[+] [-] otroquecorre|6 years ago|reply
[+] [-] apotheosis|6 years ago|reply
[+] [-] dnsfr|6 years ago|reply
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?
[+] [-] ozzmotik|6 years ago|reply
[+] [-] rushi_agrawal|6 years ago|reply
[+] [-] dnsfr|6 years ago|reply
[+] [-] kenshinji|6 years ago|reply
[+] [-] OJFord|6 years ago|reply
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.
[+] [-] matthewtovbin|6 years ago|reply