5 ms·

I mean, the man page is the Bash book to rule them all, but it's not a fun or light read. If you want to truly understand Bash you need to read it.

skulk 3y ago
I've used bash for the last 10 years but never read the man page, probably never even opened it once. Is there some nugget of knowledge that I've missed out on by learning it entirely from Google searches and Stack Exchange?
- read_if_gay_ 3y ago
  Actually, if you truly, really want to understand Bash by my personal arbitrary standard, then you must be able to produce the entire source code from memory, because that is the real book to rule them all. Sure, you might be able to navigate your everyday tasks perfectly, but that's not what matters now is it?
- chubot 3y ago
  Yeah, I've been deep in the bash manual and source code during my work on https://www.oilshell.org https://www.oilshell.org, which basically reimplements a "cleaned up" spec-driven bash (called OSH). But I also used bash for 15 years before that, and I hardly used the bash manual. I got by with a minimal / sane dialect, and I read a few books about Unix, and one about POSIX shell (the latter is also "meh"). Now that I've read almost all of the bash manual, I'd say it's not really a special document. It's fine, but it's not complete, and I wouldn't say it's particularly well written. It lacks examples. -- The main recommendation I have for anyone who wants to learn bash is to learn Unix and C. Learning the underlying model explains many things, explains the bad error messages, and makes it easier to use. https://www.oilshell.org/blog/2020/04/comics.html https://www.oilshell.org/blog/2020/04/comics.html - Three Comics For Understanding Unix Shell So yeah I don't think "learning shell" or "learning bash" is actually a great goal -- it's part of the operating SYSTEM, and you want to learn the OS, and its philosophy. related - https://www.oilshell.org/blog/2021/01/philosophy-design.html https://www.oilshell.org/blog/2021/01/philosophy-design.html - Unix Shell: Philosophy, Design, and FAQs -- Probably the most useful part of the bash manual is the acknowledgement that there's a lexing design bug with [[ and regular expressions. It's better to make the regex a separate var, like pat='[[:digit:]]+' if [[ $mystr ~= $pat ]]; then ... fi ... than to inline it, because bash does funky stuff when you inline it. It confuses regex metachars and bash metachars. It's trying (and failing) to make regexes syntaically part of the bash language, but it's better to treat it like Python, where Python syntax and regex syntax are separate.
- usrbinbash 3y ago
  `man bash` is, hands down and by far, the most accurate and complete bash resource. That doesn't mean it's a pleasant or even good read. It's terse, technical and descriptive. It's a users manual, not a textbook, and not a tutorial. But it's complete, explains everything, it's free, comes with bash, and is searchable ;-) I have spent a lot of time in there, usually when debugging or extending old shell scripts.
- eichin 3y ago
  Usually when I can't find a simple way to do something, only a messy/complicated one, I find it worth popping into the info file and looking around - as long as you're comfortable using bash-specific (vs POSIX) idioms, there's often some generalization that helps. (Having said that, stack overflow "isn't great until it is", I've found some real gems of "can't you just do this?" that vastly simplify what I was trying to do by, effectively, doing something else entirely.) That said, I think with bash (and anything with a man page more than 5 pages long - "screen" and "lsof" for example) it's worth just doing a quick skim of the entire man page once every 5 or 10 years - sure, most of it will be "yeah, I know that", and a bunch will be "... who asked for that? why do we even have that lever?" but there will be a few things that fix something that's annoyed you for years, and a few things that you'll ignore and then 6 months later you'll say "wait, I read something about this" and go back and fix the problem. (Reading the changelogs of your primary tools is also smart, and I'll admit I pretty much only do that when looking at security changes, or when looking at a weird behaviour change between releases and trying to figure out what the intent was - not that I recommend that part per se, you just become the greybeard everyone comes to with weird questions :-) Most recently, bash pipeline tail-exec...)
- throwawaaarrgh 3y ago
  There's a reason the man page is 200 pages long with 43,000 words. There's a lot more there than you imagine, much of it subtle. Once you've read it, you don't need to Google anymore. You just open up the man page to the relevant section and see all the context, rather than just one answer to one question.
  - corethree 3y ago
    Wait. Why are you reading the bash man page without fully understanding man? You need to fully understand man before reading the man bash page. Here: https://man7.org/linux/man-pages/man1/man.1.html https://man7.org/linux/man-pages/man1/man.1.html but before that are you reading that on chrome? Have you read the chrome documentation?
    - legends2k 3y ago
      While man pages may not be for reading end to end, Bash's man pages are actually Info documents i.e. They're books with clear chapters, and are intended to be read like books.
deleted 3y ago
[deleted]
wrycoder 3y ago
For a more organized read from the authors at GNU, try the online version of > info bash https://www.gnu.org/software/bash/manual/bash.html https://www.gnu.org/software/bash/manual/bash.html

skulk 3y ago

I've used bash for the last 10 years but never read the man page, probably never even opened it once. Is there some nugget of knowledge that I've missed out on by learning it entirely from Google searches and Stack Exchange?

read_if_gay_ 3y ago
Actually, if you truly, really want to understand Bash by my personal arbitrary standard, then you must be able to produce the entire source code from memory, because that is the real book to rule them all. Sure, you might be able to navigate your everyday tasks perfectly, but that's not what matters now is it?
chubot 3y ago
Yeah, I've been deep in the bash manual and source code during my work on https://www.oilshell.org https://www.oilshell.org, which basically reimplements a "cleaned up" spec-driven bash (called OSH). But I also used bash for 15 years before that, and I hardly used the bash manual. I got by with a minimal / sane dialect, and I read a few books about Unix, and one about POSIX shell (the latter is also "meh"). Now that I've read almost all of the bash manual, I'd say it's not really a special document. It's fine, but it's not complete, and I wouldn't say it's particularly well written. It lacks examples. -- The main recommendation I have for anyone who wants to learn bash is to learn Unix and C. Learning the underlying model explains many things, explains the bad error messages, and makes it easier to use. https://www.oilshell.org/blog/2020/04/comics.html https://www.oilshell.org/blog/2020/04/comics.html - Three Comics For Understanding Unix Shell So yeah I don't think "learning shell" or "learning bash" is actually a great goal -- it's part of the operating SYSTEM, and you want to learn the OS, and its philosophy. related - https://www.oilshell.org/blog/2021/01/philosophy-design.html https://www.oilshell.org/blog/2021/01/philosophy-design.html - Unix Shell: Philosophy, Design, and FAQs -- Probably the most useful part of the bash manual is the acknowledgement that there's a lexing design bug with [[ and regular expressions. It's better to make the regex a separate var, like pat='[[:digit:]]+' if [[ $mystr ~= $pat ]]; then ... fi ... than to inline it, because bash does funky stuff when you inline it. It confuses regex metachars and bash metachars. It's trying (and failing) to make regexes syntaically part of the bash language, but it's better to treat it like Python, where Python syntax and regex syntax are separate.
usrbinbash 3y ago
`man bash` is, hands down and by far, the most accurate and complete bash resource. That doesn't mean it's a pleasant or even good read. It's terse, technical and descriptive. It's a users manual, not a textbook, and not a tutorial. But it's complete, explains everything, it's free, comes with bash, and is searchable ;-) I have spent a lot of time in there, usually when debugging or extending old shell scripts.
eichin 3y ago
Usually when I can't find a simple way to do something, only a messy/complicated one, I find it worth popping into the info file and looking around - as long as you're comfortable using bash-specific (vs POSIX) idioms, there's often some generalization that helps. (Having said that, stack overflow "isn't great until it is", I've found some real gems of "can't you just do this?" that vastly simplify what I was trying to do by, effectively, doing something else entirely.) That said, I think with bash (and anything with a man page more than 5 pages long - "screen" and "lsof" for example) it's worth just doing a quick skim of the entire man page once every 5 or 10 years - sure, most of it will be "yeah, I know that", and a bunch will be "... who asked for that? why do we even have that lever?" but there will be a few things that fix something that's annoyed you for years, and a few things that you'll ignore and then 6 months later you'll say "wait, I read something about this" and go back and fix the problem. (Reading the changelogs of your primary tools is also smart, and I'll admit I pretty much only do that when looking at security changes, or when looking at a weird behaviour change between releases and trying to figure out what the intent was - not that I recommend that part per se, you just become the greybeard everyone comes to with weird questions :-) Most recently, bash pipeline tail-exec...)
throwawaaarrgh 3y ago
There's a reason the man page is 200 pages long with 43,000 words. There's a lot more there than you imagine, much of it subtle. Once you've read it, you don't need to Google anymore. You just open up the man page to the relevant section and see all the context, rather than just one answer to one question.
- corethree 3y ago
  Wait. Why are you reading the bash man page without fully understanding man? You need to fully understand man before reading the man bash page. Here: https://man7.org/linux/man-pages/man1/man.1.html https://man7.org/linux/man-pages/man1/man.1.html but before that are you reading that on chrome? Have you read the chrome documentation?
  - legends2k 3y ago
    While man pages may not be for reading end to end, Bash's man pages are actually Info documents i.e. They're books with clear chapters, and are intended to be read like books.

deleted 3y ago

[deleted]

wrycoder 3y ago

For a more organized read from the authors at GNU, try the online version of > info bash https://www.gnu.org/software/bash/manual/bash.html https://www.gnu.org/software/bash/manual/bash.html