I don't really use a cheatsheet, but I stored all of my snippets in my shell configuration file. In this case, I use fish shell.
Ask HN: Can I see your cheatsheet?
111–120 of 173 posts
Re: Ask HN: Can I see your cheatsheet?
#112As for me, I put together some spaghetti bash functions for taking note while using the terminal (eg run tnote function will let me select one of the last 10 commands, type a description of what it does and move on with my day...i can come back later and sort it out into my notes)...
I then write another small bash script that use consolemd and surge(probably will move to github page at some point) to generate a simple webpage with simple markdown JavaScript library to serve it up along with all the files generated by consolemd so i can use curl in terminal and have it colorfully displayed.
The cheatsheet site is here https://ch.ebfe.pw/.
And you can try it in terminal: curl https://ch.ebfe.pw/intel/splunk
And my code can be found here if you are interested:
Re: Ask HN: Can I see your cheatsheet?
#113Re: Ask HN: Can I see your cheatsheet?
#114Earlier quoted context omitted.
I consider myself pretty experienced at shell-fu and capable of doing most things I set out to achieve in either bash scripts or fearless one-liners. However, my awk is rudimentary at best, I think mostly because it's such an unforgiving environment to experiment in. These books you've written are great for a bit of first principles insight and then quickly building up to functional usage. I will have no hesitation i…
Thanks a lot for the feedback :) Curious about what kind of issues you had with `awk`. Perhaps https://awk.js.org/ could help? > Do you have a patreon or something similar? I pay my bills by selling PDF/EPUB versions of these books. Purchase links are mentioned in the 'Buy' page. You can also visit https://learnbyexample.gumroad.com/ or https://leanpub.com/u/learnbyexample > Do you accept pull requests for collaborat…
That AWK REPL in JS is amazing! Just what I need for a playground to refine my understanding of its language. Thank you!
I will consider buying the books and spread the word :) Thanks again!
Re: Ask HN: Can I see your cheatsheet?
#115I use navi: https://github.com/denisidoro/navi
> navi allows you to browse through cheatsheets (that you may write yourself or download from maintainers) and execute commands. Suggested values for arguments are dynamically displayed in a list.
It also lets you use cheatsheets from tldr and cheat.sh from it (besides your own cheatsheets). I've started to mostly just maintain my own, copying what I find most useful from those repositories, though.
Re: Ask HN: Can I see your cheatsheet?
#116I use my ebooks for reference: * GNU grep and ripgrep ( https://learnbyexample.github.io/learn_gnugrep_ripgrep/ ) * GNU sed ( https://learnbyexample.github.io/learn_gnused/ ) * GNU awk ( https://learnbyexample.github.io/learn_gnuawk/ ) * Ruby one-liners cookbook ( https://learnbyexample.github.io/learn_ruby_oneliners/ ) * Perl one-liners cookbook ( https://learnbyexample.github.io/learn_perl_oneliners/ ) * Command li…
I stumbled upon your vi post a few days ago, really like the style. Keep it up!
Re: Ask HN: Can I see your cheatsheet?
#117Earlier quoted context omitted.
I consider myself pretty experienced at shell-fu and capable of doing most things I set out to achieve in either bash scripts or fearless one-liners. However, my awk is rudimentary at best, I think mostly because it's such an unforgiving environment to experiment in. These books you've written are great for a bit of first principles insight and then quickly building up to functional usage. I will have no hesitation i…
The AWK Programming Language is great too. Every technical book should be written this way: describe feature, show feature through example, include cookbooks of useful commands. https://ia903404.us.archive.org/0/items/pdfy-MgN0H1joIoDVoIC...
Thanks for the link, had a quick peruse, looks very comprehensive!
Re: Ask HN: Can I see your cheatsheet?
#118I write down all my commands, ever issued in the terminal, in temporal ordered markdown files per task/project. This means I can go back, compare, see how I did it in the past and improve, if possible. Or investigate, why something isn't working (based on my noted commands, which is eaier in hindsight).
How do you format them? Mine look very verbose, I don't like markdown at all, but since Gitlab/Github renders them, you can't use anything else...
Not sure I understand the question - I use code-blocks (```ls -alh```) or inline code (`ls -alh`). Everything else is comments and descriptions, what I am doing here. I don't really need rendering, most of the time I use Notepad++, or Typora, or my own Gitlab, or the markdown-text app in my nextcloud.
Re: Ask HN: Can I see your cheatsheet?
#119Set a huuuuuuuge shell history https://github.com/craigjperry2/dotfiles/blob/aa77ddcbde63bf... then fzf ctrl+r bindings mean you can recall anything right where you need it. If you’re going to do this then have an escape hatch for commands you don’t want memorised https://github.com/craigjperry2/dotfiles/blob/aa77ddcbde63bf...
protip: use comments to remind yourself or make commands searchable, e.g.
$ find . -iname 'package.json' -exec jq .version {} \; # get npm module version numbers for all packages
$ history | grep 'npm module version'
Re: Ask HN: Can I see your cheatsheet?
#120I tried to maintain one many years ago, but I could never get in the habit of being consistent about it. So it was short-lived and didn't get much use. I do refer directly to past code all the time, and that serves me fine.