On 11/19/2012 10:32 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2012-11-19 11:26, JtWdyP wrote:
I note that some of the other posters seem to think you are not actually reading the {expletive deleted} manuals. But what I think I'm seeing is somebody having a hard time understanding the {many expletives deleted} manuals.
No expletive. It means "Fabulous" ;-)
I know that I almost always have a hard time understanding what they mean myself. I mean I can usually use them to remind me of something I used to know. But if they wanted me to actually learn something new from them, they would do better to include many more actual usage examples, instead of just describing the usage in such highly technical terms that it often merely confuse me.
Yes, man pages are guides for some one that already knows how to use the program in question. Most of them, anyway, with notable exceptions like procmail(ex). Howtos are much better.
If I'm right all I can say is keep plugging, eventually you'll at least learn some of it. But they are right too. The "man pages" and "info documents" are usually your best source of information on a command. Unfortunately they seem to be written like college text books, with the expectation that the student will be guided by some professor or some such thing.
Yes.
Man pages job is to be accurate above all else. You usually can't be accurate and at the same time be easy to read. They must not say anything that is untrue. In that sense they end up sounding like "legalese" or the way practically every scientist talks. How-to's are nice, and necessary, but they cannot be accurate, because how-to's, in the interest of being easier to follow, simply leave a lot out and make a lot of arbitrary assumptions. That makes them only true for the one specific situation and context they happen to be describing, and wrong for for every other infinite situation. They narrow the infinite possibilities down to one single example. The example is nice, but the example is not the definition. In real life there are very few absolutes, so the accurate description of how a program works is chock full of relative references and almost no absolutes. That makes it hard to read for the inexperienced because every other word is a variable instead of a simple value. It's like reading math equations instead of prose. Well that's entirely appropriate since this is a computer not a novel. A how-to says "run this command" and gives some string of stuff for you to copy like a monkey. But that is wrong because that example is not "how you do it", it is just one of infinite ways to do it, and it is the wrong way if taken outside of the context that was either set up, or worse just assumed, by the howto itself. A how-to says, "remove foot from brake pedal, depress gas pedal" The manual must never do that. If you read something in the manual and do it, and it's wrong, you will howl and curse the author for lying to you and causing your machine to crash and erase your data. If you read the above in a manual, and did it, you could run over a cat or crash into a building etc. The manual must only ever simply describe what the brake pedal does, what the gas pedal does, and all the other knobs and levers. It's up to you to decide when and where it's time to press the gas and time to press the brake by having the knowledge of what they both do. Sometimes they do include a few skeletal examples but they can't realistically do more than that. Consider "man bash". bash is not merely a program but a whole programming language which can do anything. How can you give a how-to and examples for bash? It would go on for infinity. Read every shell script on your system, then read every shell script you can find on the net by google, they are all correct how-to's for bash. They are great for mining examples out of, but the manual needs to be distilled down to the rules, and then you use those rules however you want. The manual can't tell you how to employ the rules it's describing any more than a dictionary can tell you how to write a document, whether to follow the form of a letter or an article or a poem or a novel. What words to use in what order. The dictionary can't know what your needs are at the moment. Not all programs are as infinite as bash, but most are flexible enough that their man pages will have more variables than absolutes, and all of them are run within the context of the unix system, which itself is highly mutable and affects every program used within it. "cat" or "dd" only do one tiny dead simple thing, and yet even they can't be described in absolutes. If you gave an example "How to read the first 512 bytes of the boot block with dd: 'dd if=/dev/sda bs=512 count=1 |od |less' Every single thing there except "dd" and "bs=512 count=1" is wrong for some and right for some. Welcome to computers. Or at least, welcome to a computing environment that actually gives you choices and power. Simpler systems exist that are easier to learn, and they simply do less. Here you can do practically anything, and the trade-off is, you have to learn how to assemble the answer to your unique wishes out of tools and parts. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org