3 ms·
Just so you know, manuals aren't read like story books, from beginning to end. They're arranged in a tree structure with the root/trunk giving a rough Overview
by jolmg 8y ago
Just so you know, manuals aren't read like story books, from beginning to end. They're arranged in a tree structure with the root/trunk giving a rough Overview or Introduction on whatever the manual is about, the branches explaining various features in broad terms and ordered by their importance, and the leaves explaining the most arcane details you might eventually need to know about.
What I do is first take note of whatever seems like a Table of Contents which neatly lays out this tree-like structure with one-line summaries. Pay attention to each title, remembering their existence for future reference, and determine how much you want to know from the get-go. Of course, the root/trunk, otherwise known as Overview or Introduction, will be relevant to everything so go over it. Only go to the deepest branches/leaves when you're planning on using that knowledge, but always go over the branches that lead to those leaves.
That about covers it. For example, there was recently a question on SE on what had higher precedence in the shell, the | or the &&. Had this person gone over the shell grammar section of the bash manpage, the answer would've been obvious:
> Pipelines: A pipeline is a sequence of one or more commands separated by one of the control operators | or |&.
> Lists: A list is a sequence of one or more pipelines separated by one of the operators ;, &, &&, or ||, and optionally terminated by one of ;, &, or <newline>.
By the way, some answers say that you shouldn't go over the manual unless you want to know a detail, but I think it sometimes pays off to read it whole (or most parts of it). I've read most of the manuals for vim, bash, i3, urxvt, among others, and I can say, it has paid off. This might depend on how you learn best, though.
- kazinator 8y ago> Just so you know, manuals aren't read like story books, from beginning to end. Yes they can be! And if you're working a great deal with some technology, it behooves you to read the manual from cover to cover. Try it! I've read a number of programming language standards from cover to cover, after which my facility greatly improved. After I read the GNU Make manual from cover to cover, I was able to understand complex Makefiles like never before, never mind generate them from scratch. At university I read a Motorola 68000 architecture spec from cover to cover (while writing an emulator). My ability to code MC68K assembly shot through the roof. I haven't read the entire POSIX standard cover-to-cover (not even the much smaller classic 1990 version), but sections of it, like the complete description of the Shell Command Language. My ability to write robust shell scripts shot through the roof. I've read the complete manuals for GNU Flex and Bison, plus the POSIX descriptions of these and other materials. Complete whiz here. Highly recommend cover-to-cover. Problems is, standards have gotten a lot thicker. Everything takes more time. You have to choose wisely and prioritize. > branches explaining various features in broad terms and ordered by their importance, and the leaves explaining the most arcane details you might eventually need to know about. That simply isn't how most technical manuals work. Once you get past the intros and overviews, the arcane details are spread throughout all the descriptions like raisins in a pudding. Generally, the description of a specific feature or construct is completely given in one lump, with all the arcane details. If there are four paragraphs, the first two may be general, the second two full of arcane details. If you don't read the arcane details, you could be screwed. Oftentimes, you're reading this stuff because of the arcane details, not because you don't get the gist of it.