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"
I’m excited about this book and appreciate your work!
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).
Cool, couple of comments. The website it a bit broken on mobile (at least for me) since text goes off the screen. Second, it would be good to have some sample pages or at least a page of contents so people can see the level of detail the book is aimed at. I know I could just get the book for free and then pay later but that kind of a faff and I feel bad choosing $0 for these kinds of things.
These two tweaks should improve it (by preventing the largest text and book graphic from overflowing the viewport horizontally on some smaller screen sizes):
Because generally a manual is “here is every single detail of this thing”, while a book like this is “here’s an overview of the particularly useful stuff.”
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.
Different people prefer different formats for information. Some people prefer to read the manual from start to finish while others learn better seeing the same concepts in a hands-on tutorial.
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.
Yes, the linked sample pages are just randomly taken pages from the book PDF, as I put it together quickly for the Show HN. Apologies. I will make a better example when I rework the landing page.
I wanted to demonstrate the use of the substitution, not the best way to diff directories. Often I tried to create examples that demonstrate multiple concepts or tools at once to save space. But I see your point.
Any resources or suggestions for how to find projects or exercises for each section?
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.
Is your focus on older tools that tend to be on most machines and used in older shell scripts (e.g., find and grep), or on newer and upgraded tools (fd, fzf, rg) that developers install on their own machines, or both?
The older standard tools, because they can be easily put in CI pipelines and shared as scripts with coworkers.
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.
If you want to use make, power to you, it’s definitely a useful tool. (What I’m trying to say is I’m bashing make, not you.)
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.
I agree too, Just (and others) are better as a pure entry point. But when you come to projects that already have Makefiles, or you know you have just one less thing to install in a container... you use Make.
In the era of micro services and ephemeral computing runtime, the baseline default environment will save us from unnecessary complexity.
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.
These days people have a tendency to grab a latest and shiniest tools when the existing ones are hard to use. Because it takes more effort to understand them than install new ones.
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.
A compelling idea, but cmake writing endif(), find_package() being the equivalent of ‘from package import *’, and CXX automatically getting re-named to CMAKE_CXX_COMPILER is just bad design. There’s no deeper idea to explore. The system is just ugly and confusing.
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*!
I just changed the payment model before posting it here, so there is no past data on this. I don't expect it to generate revenue compared to normal sales (it will most likely be a small fraction). But for normal sales you need to be able to promote it.
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 :)
The content seems really great, however the typesetting makes it quite hard to read:
* 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.
This is excellent! Thank you for posting and best wishes for your success with this!
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 :)
It makes me wonder – what's that one command or concept you CLI vets wish you'd learned way earlier that totally changed your game, something that might be in that 'next 20%'? Curious about those 'aha!' moments!
bat # cat with syntax highlighting
zoxide # keeps track of directories
tig # ncurses git viewer
atuin # shell history across machines
choose # easier cut or "awk '{print $1}'"
direnv # set environment vars when you enter a directory
fd # better find
fzf # fuzzy find anything, total game changer
gh # GitHub client
rg # really fast recursive grep
One of my favorites from the book is to alias "xdg-open" to "open" because I never remember the command. So now I can just type "open X" to open a file system location or file in a normal GUI program when needed. It is a small thing but I use it a lot.
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:
grep, sed, awk and regular expressions would probably be part of my 1st hour course if I were to produce one. And by awk I mean the super basic stuff like -F',' '{print $3" "$NF}' is already a long way
also any command | while read line; do something $line; done
because for one it doesn't mess with stdin, and for another you don't have to worry about filenames with spaces or newlines in them. I also like -execdir since if my script dumps any output to other files I'll probably want that output near the sources. And did I mention it does nothing if there are no matching files? I also think it looks better and is shorter.
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.
Interested, but going to the website told me nothing other than a book about the command line.
Would be nice be able to get a preview of a some pages/chapters.
Noted. For now I put links here, in the comments, and in the Gumroad page to sample pages. I will need to change the homepage later. Thanks for the input!
#1 thing in command line shell scripting should be: "Do not use it for advanced scripts. If you have multiple if statements and for loops, rewrite it in a higher level language."
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.
I would not say it is trash, but I tend to agree with the general sentiment and personally don't write longer scripts.
> 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.
Cryptic, overly complicated syntax. for loops, if statements, etc.. are all done better in other languages.
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.
cool! Even though it’s getting easier to use AI to generate commands these days—I often ask AI to help me write commands myself—I still think it’s important to understand and systematically learn the command line. I’ll definitely recommend this book to my friends. One suggestion: maybe you could include some practical examples from real work scenarios in the book to make it even more approachable and engaging.
I don't want to just add to it because the entire idea is to have a short book, but I will be thinking about replacing/improving some sections. The examples already demonstrate the practical scenarios, but I think there could be a few sentences about how a particular concept can be used in real world scenario.
DevOps is not very specific term... so hard to list specific things to learn. But it certainly will be much, much more than just shell/command line knowledge.
I definitely recommend to try things as you go along, copy paste things and run them yourself. As for the timeline, everyone is different. My own take is that learning always takes time and repetition, so I would not rush it and focus on practice.
Not for now. But I am happy to send you the PDF by email and receive a donation via PayPal if the reason is not to fund Gumroad. Just contact me on petr@stribny.name or @stribny on X.
Honestly I would’ve liked to fork over cash for a book like this but the deal breaker for me is that it’s in PDF format. I like to read all of my books on a Kindle (with koreader installed) so epub files that can be resized to fit its weird dimensions are a must.
Noted. I will try to provide alternative formats. Not sure how it will go with the code examples, but I shall try.
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.
That's a big ask. I've written a couple of books, and PDF/print vs. ePub/webpage is a decision I had to make up front. For anything with more than the most basic formatting (e.g. a novel), the design and layout are different enough that one of them will turn out looking like crap. Given the audience, I probably would have chosen ePub for this one, but the book's done now.
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.
Honestly I haven't tried yet. Maybe Asciidoctor (Which I used) has it figured out. It would at least need to have good enough output for the code examples, otherwise it would probably be a non-starter.
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.
For what it’s worth I would have purchased if this was available in physical form (I’m weighing purchasing anyway, but my personal hunch is I’d pay $20-30 for physical copy and probably $10-20 for pdf).
Amazon makes it quite easy to publish books that get printed on demand, and they accept pdf files as inputs.
Thanks for the input. I have made several updates to the book in the past and this would be lost in print, but as the book matures and I incorporate feedback it can be interesting to try offering a print version. Perhaps print-on-demand type of thing.
Honestly I would’ve liked to fork over cash for a book like this but the deal breaker for me is that it’s in PDF format. I like to read all of my books on a Kindle
When I made my purchase, the options were Download and Send to Kindle. It's not ePub, but it's something.
Cool book!
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"
True, the landing page could be more detailed. I didn't want to repeat much the info on Gumroad page, but maybe I should rethink it.
And thanks for the copy suggestions. I am not a native speaker :)
I’m excited about this book and appreciate your work!
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!
Thank you!
Yes, as other people pointed out too, the landing page could do with some mobile and copy improvements.
A note on English: "Fresh off the press" is the colloquialism you're looking for, not "Fresh out of press."
Thanks!
I definitely think you should add more info to the landing page - I had no idea there was further information on the Gumroad page.
Cool, couple of comments. The website it a bit broken on mobile (at least for me) since text goes off the screen. Second, it would be good to have some sample pages or at least a page of contents so people can see the level of detail the book is aimed at. I know I could just get the book for free and then pay later but that kind of a faff and I feel bad choosing $0 for these kinds of things.
Thanks for the feedback. I was trying to make it work on mobile but maybe I didn't test it well in the end.
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...
One nit: ^D only exits if the cursor is at the beginning of a line. Enter <space>^D and the session remains.
Otherwise, looks good! Use of "env" and proper quoting are strong signals!
Thanks for the clarification. I will see if I can sneak in a note about this in the next update :)
page 112
> 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 agree with all this. I'm on Firefox android, pixel, lose part of the screen too.
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"!
> I agree with all this. I'm on Firefox android, pixel, lose part of the screen too.
Ah okay, I really wasn't aware. Thanks for reporting.
I am also seeing text off the screen using Brave on Android.
You are right. It is wrong, will need to look into this.
These two tweaks should improve it (by preventing the largest text and book graphic from overflowing the viewport horizontally on some smaller screen sizes):
Also, I really like what I see in your book so far and I am already learning things on the first few pages. Thanks!Oh that's great. Thanks!
Example pages here: https://drive.google.com/file/d/1PkUcLv83Ib6nKYF88n3OBqeeVff...
I consider myself reasonably proficient in the shell, but I learned something just from your sample pages (process substitution). Purchased!
Thanks!
If you have not skimmed through the manual of bash¹ enough to learn about process substitutions, what makes you think you would read a book?
1. <https://www.gnu.org/software/bash/manual/bash.html>
Because generally a manual is “here is every single detail of this thing”, while a book like this is “here’s an overview of the particularly useful stuff.”
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.
Different people prefer different formats for information. Some people prefer to read the manual from start to finish while others learn better seeing the same concepts in a hands-on tutorial.
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.
Maybe because they didn't think to?
Page 12 of the example pdf ends with "On Linux, the PATH looks something like this:", but then there's no PATH example shown.
Yes, the linked sample pages are just randomly taken pages from the book PDF, as I put it together quickly for the Show HN. Apologies. I will make a better example when I rework the landing page.
Page 13 isn't in the example pdf. It's a bunch of scattered pages to give you a feel for the whole thing.
Hmm, the example page doesn't convince me, for example
> 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 think it was about demonstrating process substitution. You don't pass a bunch of files to diff, you pass the output of ls, as a file, to diff.
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 wanted to demonstrate the use of the substitution, not the best way to diff directories. Often I tried to create examples that demonstrate multiple concepts or tools at once to save space. But I see your point.
if you add a cover page with http link, an example download read at a later time will find its way back more easily. Looks good!
Thanks for the suggestions:)
Any resources or suggestions for how to find projects or exercises for each section?
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.
Folks interested in this will also appreciate The Shell Haters Handbook: https://shellhaters.org/deck/
Also don't miss https://wizardzines.com/
Is your focus on older tools that tend to be on most machines and used in older shell scripts (e.g., find and grep), or on newer and upgraded tools (fd, fzf, rg) that developers install on their own machines, or both?
The older standard tools, because they can be easily put in CI pipelines and shared as scripts with coworkers.
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.
<3 GNU Make
Make is a powerful self-documentable tool. It can hide tons of complicated dependencies implementation details behind a simple and universal CLI.
If you want to use make, power to you, it’s definitely a useful tool. (What I’m trying to say is I’m bashing make, not you.)
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.
I agree too, Just (and others) are better as a pure entry point. But when you come to projects that already have Makefiles, or you know you have just one less thing to install in a container... you use Make.
In the era of micro services and ephemeral computing runtime, the baseline default environment will save us from unnecessary complexity.
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.
These days people have a tendency to grab a latest and shiniest tools when the existing ones are hard to use. Because it takes more effort to understand them than install new ones.
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.
A compelling idea, but cmake writing endif(), find_package() being the equivalent of ‘from package import *’, and CXX automatically getting re-named to CMAKE_CXX_COMPILER is just bad design. There’s no deeper idea to explore. The system is just ugly and confusing.
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*!
We can use LLM to read and write cmake as well. They are all Turing machines anyway.
How has the "pay what you want" model worked out if you don't mind me asking? It's something I've thought about in the past for selling courses.
I just changed the payment model before posting it here, so there is no past data on this. I don't expect it to generate revenue compared to normal sales (it will most likely be a small fraction). But for normal sales you need to be able to promote it.
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 admire your mindset (and humility). Thanks for making this available.
Good resource to couple this resource with: https://linuxjourney.com.
See also this open source version inspired by that site: https://github.com/daquino94/linux-path
I wrote interactive TUI apps with exercises for Linux CLI tools, coreutils, grep, sed and awk: https://github.com/learnbyexample/TUI-apps
The content seems really great, however the typesetting makes it quite hard to read:
* 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.
Thanks for the feedback.
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.
Nice work, I've been using linux 20+ years and learnt something from the example pages. (edit, just realised it's closer to 30 now, jesus)
Thanks!
This is excellent! Thank you for posting and best wishes for your success with this!
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 :)
Thank you for the nice words :)
It makes me wonder – what's that one command or concept you CLI vets wish you'd learned way earlier that totally changed your game, something that might be in that 'next 20%'? Curious about those 'aha!' moments!
One of my favorites from the book is to alias "xdg-open" to "open" because I never remember the command. So now I can just type "open X" to open a file system location or file in a normal GUI program when needed. It is a small thing but I use it a lot.
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!
In my Linux install (Debian 12/Bookworm) /usr/bin/open is a symlink to /usr/bin/xdg-open so I was always using xdg-open without even knowing it.
Great somebody thought of it!
grep, sed, awk and regular expressions would probably be part of my 1st hour course if I were to produce one. And by awk I mean the super basic stuff like -F',' '{print $3" "$NF}' is already a long way
also any command | while read line; do something $line; done
and find and vi of course
These might seem basic but they made a huge difference when I learnt them:
Get really comfortable with find and grep. They’re incredibly powerful. perl -pe is way easier than awk.
I'll second that. And would like to add that find plus xargs is important to know, as it often works much better than the clumsy "exec in find itself.
Oh, and thus of course
to do some fancy stuff with found files ;-)I really think you should use:
because for one it doesn't mess with stdin, and for another you don't have to worry about filenames with spaces or newlines in them. I also like -execdir since if my script dumps any output to other files I'll probably want that output near the sources. And did I mention it does nothing if there are no matching files? I also think it looks better and is shorter.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!)
the basics of awk and perl, these days jq as well.
Looks very nice!
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.
Thanks.
You teach this in a classroom?
I do, it's given as a seminar twice a year.
Nice! At least you get your feedback in real time, see what people struggle with and so on. That can be very useful.
Interested, but going to the website told me nothing other than a book about the command line. Would be nice be able to get a preview of a some pages/chapters.
Noted. For now I put links here, in the comments, and in the Gumroad page to sample pages. I will need to change the homepage later. Thanks for the input!
#1 thing in command line shell scripting should be: "Do not use it for advanced scripts. If you have multiple if statements and for loops, rewrite it in a higher level language."
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.
I would not say it is trash, but I tend to agree with the general sentiment and personally don't write longer scripts.
> 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.
"I might come to work on..."
Friend, you have no idea LOL
My hatred is well earned!
Is there an explanation why? (Average line count in my scripts is 115).
Cryptic, overly complicated syntax. for loops, if statements, etc.. are all done better in other languages.
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.
cool! Even though it’s getting easier to use AI to generate commands these days—I often ask AI to help me write commands myself—I still think it’s important to understand and systematically learn the command line. I’ll definitely recommend this book to my friends. One suggestion: maybe you could include some practical examples from real work scenarios in the book to make it even more approachable and engaging.
I don't want to just add to it because the entire idea is to have a short book, but I will be thinking about replacing/improving some sections. The examples already demonstrate the practical scenarios, but I think there could be a few sentences about how a particular concept can be used in real world scenario.
Thanks for sharing:)
If one reads a book like this and becomes good at the command line. How much do they still need to grok/pickup from devops to be competent at it?
DevOps is not very specific term... so hard to list specific things to learn. But it certainly will be much, much more than just shell/command line knowledge.
Just bought it. Any advice on how to use the book to master the terminal? One page a day or try to finish everything in a week or two?
I definitely recommend to try things as you go along, copy paste things and run them yourself. As for the timeline, everyone is different. My own take is that learning always takes time and repetition, so I would not rush it and focus on practice.
Wow. This is amazing. I really like the way you use color and do footnote-like explanations.
Thank you!
Any alternatives to Gumroad in buying this?
Not for now. But I am happy to send you the PDF by email and receive a donation via PayPal if the reason is not to fund Gumroad. Just contact me on petr@stribny.name or @stribny on X.
Why?
Honestly I would’ve liked to fork over cash for a book like this but the deal breaker for me is that it’s in PDF format. I like to read all of my books on a Kindle (with koreader installed) so epub files that can be resized to fit its weird dimensions are a must.
Noted. I will try to provide alternative formats. Not sure how it will go with the code examples, but I shall try.
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.
That's a big ask. I've written a couple of books, and PDF/print vs. ePub/webpage is a decision I had to make up front. For anything with more than the most basic formatting (e.g. a novel), the design and layout are different enough that one of them will turn out looking like crap. Given the audience, I probably would have chosen ePub for this one, but the book's done now.
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.
Honestly I haven't tried yet. Maybe Asciidoctor (Which I used) has it figured out. It would at least need to have good enough output for the code examples, otherwise it would probably be a non-starter.
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.
For what it’s worth I would have purchased if this was available in physical form (I’m weighing purchasing anyway, but my personal hunch is I’d pay $20-30 for physical copy and probably $10-20 for pdf).
Amazon makes it quite easy to publish books that get printed on demand, and they accept pdf files as inputs.
Thanks for the input. I have made several updates to the book in the past and this would be lost in print, but as the book matures and I incorporate feedback it can be interesting to try offering a print version. Perhaps print-on-demand type of thing.
Amazon does print on demand. I have a book published there that I sell at cost and it’s about $8 shipped. Print quality is pretty good.
If you make changes, you just upload a new template and you’re all set.
Thanks for the tip. I will explore it.
Yeah, same. On a phone or smaller e-reader, regular PDFs designed for normal book size are often unreadable.
You can use calibre and convert it, most of the time the result is very good.
Have you tried pdf reflow with koreader? I find it works pretty well
Honestly I would’ve liked to fork over cash for a book like this but the deal breaker for me is that it’s in PDF format. I like to read all of my books on a Kindle
When I made my purchase, the options were Download and Send to Kindle. It's not ePub, but it's something.
Looks nice! Purchased a copy. :-)
Thank you
Sorry, but it would be great to adapt it for the mobile layout.
Do you mean the website or are you talking about the book PDF?
I meant the website.
Ahh yes, the lost art of UNiX sys admin always comes back.