Show HN: I wrote a modern Command Line Handbook
A few years back I wrote an ebook about the Linux command line. Instead of focusing on a specific shell, paraphrasing manual pages, or providing long repetitive explanations, the idea was to create a modern guide that would help readers to understand the command line in the practical sense, cover the most common things people use the command line for, and do so without wasting the readers' time.
The book contains material on terminals, shells (compatible with both Bash and Zsh), configuration, command line programs for typical use cases, shell scripting, and many tips and tricks to make working on the command line more convenient. I still consider it "an introduction" and it is not necessarily a book for the HN crowd that lives in the terminal, but I believe that the book will easily cover 80 % of the things most people want or need to do in the terminal.
I made a couple of updates to the book over the years and just finished a significant one for 2025. The book is not perfect. I still see a lot of room for improvement, but I think it is good enough and I truly want to share it with everyone. Hence, pay what you want.
EXAMPLE PAGES: https://drive.google.com/file/d/1PkUcLv83Ib6nKYF88n3OBqeeVff...
Humble suggestion: Give more specific examples of what the reader will learn on the landing page. From the landing page, I don't know if this is for total command line beginners or has helpful tips for people familiar with bash already. I had to hunt around to find sample pages, and they provided much better sense of what's in the book.
Also, spotted some small issues in the copy:
"Fresh out of press" - The more common expression is "hot off the press." "Out of press" sounds similar to "out of print" (i.e., no longer sold)
"Grok the Linux command line on only 120 pages" - should be "in only 120 pages"
And thanks for the copy suggestions. I am not a native speaker :)
One thing that was distracting was the large title font when I tried to view this site in portrait mode on mobile, as some of the letters are cut off. If that could be fixed, it would help ensure people stay engaged and read it.
You could also potentially use an LLM or something like Grammarly to help proofread it (not edit it).
This is very cool!
Yes, as other people pointed out too, the landing page could do with some mobile and copy improvements.
As for a sample, I will go and try to make something now. Thanks.
Edit: Example pages here: https://drive.google.com/file/d/1PkUcLv83Ib6nKYF88n3OBqeeVff...
Otherwise, looks good! Use of "env" and proper quoting are strong signals!
> if [[ "${1-}" =~ ^-*h(elp)?$ ]]; then
> ... is an option that starts with one or multiple - characters ...
"one or multiple" is + not *. The regex above will also match "h" and "help" without - character(s).
I'd love to read a table of contents. I don't want to rip you off with zero dollars!
Anyway, sounds like a great book. Congratulations on completing and "shipping"!
Ah okay, I really wasn't aware. Thanks for reporting.
1. <https://www.gnu.org/software/bash/manual/bash.html>
I’ll go to the manual if I’m trying to understand how a particular thing works, or how to do a particular thing, but it’s not as useful to me for feature discovery.
From reading the sample of OP's book, it seems far more practical and accessible than the bash manual, so I'm not surprised that a lot of people would read OP's book that have no interest in reading the bash manual cover to cover.
> The diff utility can compare files and print their differences. If we pass it the result of ls commands, we can compare the contents of directories.
No, if you pass the output of ls commands, you might get an error because you'll pass a bunch of files to diff.
And last but not least there's
to compare two directories file by file.I actually thought it was awesome to see that. I use this a lot to diff the output of commands and many people don't know about it.
I need to train some people (who will never use the command line and will go back to excel and VSCode, but I am not the genius who decides what people have to be competent in…) and this book is great, but I don’t think they are motivated enough to learn without some projects or problems and I struggle to invent nonsense projects.
For example, in my personal and professional life I use Make everywhere. The book mentions alternatives, but the examples are built on the time-tested tools.
I focused on things that don't require install (if given the option) or the ones that you are more likely to encounter at work. It is a tradeoff and I can see how the reverse would be appealing too.
That being said, I absolutely hate make, there are so many footguns and weird quirks and implicit behavior that always end up biting me.
I find that 90% of the time what I actually want is a command runner like Just (https://github.com/casey/just) and have the make file contain the absolute sheer minimum required to build code.
While we’re at it, CMake is another build tool with the same problems as make - powerful, with an ugly syntax, unintuitive semantics, hidden dragons, and a manual that’s torturous to read.
With LLM, we might have a chance to explore the capabilities and deeper ideas in them. If I have enough LLM budget (time and money wise), I might spend more on using awk to build super agents. GNU manuals are perfect context for these kinds of usages.
I’ve been reading through https://cliutils.gitlab.io/modern-cmake/README.html to try and get my head around CMake best practices and the book is just line after line of “Don’t do it the old way or the obvious way, because you will end up accidentally doing the wrong thing due to A Hidden Footgun.” That’s bad design*!
For example, in CI pipelines, I can use my own plain. Makefile to replace different yaml tasks across different languages, from shell scripts to python scripts to npm scripts.
* Code blocks on a subsequent page to the explanation, especially when there is enough space to show it (p18/19)
* Call-outs as above (p26/27)
* Single words broken by a page (p51/52)
* Footers spanning multiple pages (p61/62)
It sounds quite nitpickey but I find it really breaks the flow when I’m reading, and trying to comprehend a section requires scrolling back and forth between two pages.
I agree and I try to keep it as nice as I can, but it can be hard to do when the book is being updated and the content changes.
Nevertheless I will be mindful of it for the next update.
My primary motivation is to share the work that I spent a lot of time on because I want to move on and work on other things (I don't want it to just sit on my disk when it can be useful to others before getting outdated etc.). It never was meant to be some primary source of income. In that case I would be writing a book about AI :)
Maybe I will write a blog post with some reflections about making the book at some point :)
I'm teaching a class next year that'll have college-level students learning to use the command line and this looks perfect. Nowadays most 'learn the shell' resources online seem to focus on how to write scripts, without explaining how to use it interactively. Given this will be (for many) their first experience with a command line stuff like "type your command, then press enter", or "Up arrow to go back through your history" are a necessary foundation for them. Not to mention stuff like Job Control and using AI to help you create the more complicated commands that folks need to do - nicely done!
Plus, the book is inexpensive enough that they can still afford other resources too :)
Definitely gonna recommend this next year :)
Something that I didn't put in the book because I learned it only recently is the use of "notify-send", aka you can send yourself a system notification from the command line or script (at least it workd for me in Gnome). For instance once a task is finished:
> echo "when finished send notification" && notify-send "system notification"
Pretty cool if you ask me!
also any command | while read line; do something $line; done
and find and vi of course
Oh, and thus of course
to do some fancy stuff with found files ;-)If you really can't remember that or want to continue to pollute the environment with extra heat generated by running two cpus to do the job one can do, you should at least use -print0/xargs -0 because of spaces, and always use -r to more sensibly handle an empty result-set from find et al (gnu xargs runs once!)
I have an interactive tutorial I wrote and teach with which is here: https://github.com/JulianEducation/CommandLineBasics in case it's useful as well. I only have 90 minutes in my case so it's a constant battle to tweak what I can get to with my audience, so there's still lots of things I want to change.
But I think it's very important to have lots of resources here so I'm excited to look at yours.
You teach this in a classroom?
Thanks for sharing:)
Edit: One reason why I picked PDF is that I expect the readers to actually follow the examples in their own terminal while going through the book. So in that sense I was thinking about reading it on the desktop.
Amazon makes it quite easy to publish books that get printed on demand, and they accept pdf files as inputs.
If you make changes, you just upload a new template and you’re all set.
Also, a TOC and sample chapter would be great. A lot more people will be likely to pay if they know what they're getting.
I added links to example pages (which include TOC) to the Gumroad page and here, but yeah I should have put it on the homepage.
When I made my purchase, the options were Download and Send to Kindle. It's not ePub, but it's something.
This is also the advice given in the google shell guide.
I say this after years of being a DevOps and Platform engineer. Bash is trash. It is great for 10-20 line scripts. Beyond that, it is worthless.
> This is also the advice given in the google shell guide.
This advice is also given in this handbook :) But in reality you might come to a work repo that already has such scripts and it is good to understand it a little bit, I would think.
Friend, you have no idea LOL
My hatred is well earned!
No package manager, build, or dependency features. This means it is ugly and gross to import functions from other programming languages.
Zero data structure support, so any data manipulation is horrible.
No test support, so you can't mock and test business logic.
No debugger support.
It's just a bad, cryptic, confusing language that is hard to maintain.
Remember: it's not that you CAN'T do these things, it's that they work better in other languages, like Node or Python. And shelling out in Python or node works great and is very easy. And Python comes built into most systems these days.
It is hard to justify writing shell scrips anymore. It's like writing perl or cobol. We have better tools now, the world has moved on.