Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Even the document I cited conceded that there are some very good Unix man pages — BSD Awk may very well be one of many, I have not read it. It follows, logically, that there could be some very bad Info documentation manuals, and the GNU Awk manual may very well be one of many; I have not read it.

This does not disprove the point the citation made; namely, that the Unix man page structure is unsuitable for many things since its structure tends to make people write manuals badly, and there is no place for the kind of introductions and tutorials that good manuals should contain. On the contrary, the man page format lends itself to very strict and terse reference documentation, which is not what I would call a “manual”, as such.

Someone should perhaps do a study of which of the two formats seem to generate the better documentation.

> The bit that pisses me off is: man awk (see info awk instead). I think they fixed that but it was a pain in the butt for years. Is it in man or is it in info?

The official GNU system documentation is in Info. Now, the GNU system is meant to be compatible with Unix, and Unix uses man pages. And since many GNU tools were (and are) not actually developed to be used in the GNU system as such, but instead find their major use and development as parts of various Unix variants, it follows that most of them have Unix have man pages too. Since writing documentation is work, and writing duplicated documentation is even more work, the man pages for GNU tools are often overly terse, incomplete and/or out of date compared to the Info documentation, which is the official documentation. Some well-known exceptions exist, notably GNU Bash does not have any Info documentation, but instead has an (enormously long) Unix man page.



> The official GNU system documentation is in Info

There is nobody in the world outside of the GNU foundation who prefers using info pages to man pages.


(You are demonstrably wrong, but I will address your implied point instead of your hyperbole.)

I think that the hostility to Info comes from exposure to the standalone Info reader. It is non-intuitive, non-Unix-like, and does, as far as I know, not even support text attributes, so it looks bad even for a text-based UI. It is not very newbie friendly (like GNU nano with its very explicit menus to guide you). Nor is it consistent with other Unix-based text UIs like “vim” or “less”. Instead it behaves like a brain-damaged Emacs, but without even many basic text-navigation features from Emacs, so even Emacs users feel lost in Info.

I feel that if someone made a module for vim or something to read and navigate Info documentation (and made it the default instead of the barebones standalone Info reader), then Unix people would warm up to Info documentation.

Personally, I read Info documentation using the Emacs built-in reader. It is, unofficially I think, the canonical Info documentation reader, and it is beautifully integrated with Emacs. I prefer reading most manuals this way (if they have an Info version).


My problem with info is the document structure. The manual for each application seems to be structured so differently with topics under specific titles and subtitles, I always get lost and it takes me a while to find the thing I'm looking for. And it really is frustrating to stumble in the dark looking for that one command line flag or input format that you've found and used many times before.

For me the consistent reference-like structure and terse language of man pages is ideal. The whole document is shorter than a bunch of info pages will be, and because of the structure, I always know where to expect specific things to be. Some man pages do not quite fit the traditional model so there is a bit of compromise, but I still find it easier to scan through such pages and remember the location of things than I do with info pages.

The difference between (Open)BSD and GNU/Linux world man pages is that the former group spend plenty of effort on polishing the language & structure to make the text clean, short and to-the-point, as well as consistent. So exactly the qualities I prefer man for are taken as far as possible. And because we love well written man pages, there's a man page for damn well near anything in the base system; whereas on other systems you're sometimes looking at info pages, sometimes html documentation installed where-ever or nowhere, READMEs, comments in config files, howtos and tutorials via Google, or at the source because nobody bothered write real documentation. If the source isn't at hand or you don't have the time for it, you try imitate what you see in use already, and pray..


> My problem with info is the document structure. The manual for each application seems to be structured so differently with topics under specific titles and subtitles, I always get lost and it takes me a while to find the thing I'm looking for.

Use the index – it’s what it’s there for. In the usual Info readers, it’s the “i” key. This is what I use when, for instance, reading the GNU C Library manual and wanting the documentation for a specific function, struct or macro. If you want the command-line switches for the “foo” command, the node to go to in the manual you find yourself when invoking “info foo” is called “foo invocation”; you go to a specified node using the “g” key. Then you simply use the space key to navigate serially through all the following nodes. There are only three more keys that I use when reading Info documentation.¹

I think it’s mostly a question of habit. Man pages has taught you to read mostly the whole document quickly, while scanning for the information you need. These are habits unsuitable to both to reading a book of printed documentation or Info documentation. If you have a specific idea of what you want to find, you use the index.

1) The “l” key – “l” for “last” – corresponds to a web browser’s back button, the “u” key goes “up” in the document tree, and the “t” key goes to the top of the current document. These five keys are all the keys I use for Info navigation, except for normal searching with C-s, but that’s Emacs. This should not be difficult, but it is. I suspect, as I wrote previously, that it’s not Unix-y enough.


The index is the problem. The index for each application and library looks different. There are headings and subheadings and subheadings.. sometimes they're descriptive enough to help you find what you need, but in my experience, they often are not. But in either case you still need to read through them and interpret them. And reading through tens of headings is a pain, especially if after reading them you navigate to the seemingly most relevant page and find it doesn't have the information you need. ("Where the hell was it?!" is something I've said more than once, trying to battle info documents.) This is what I mean when I complain about structure; it's not consistent, it's not predictable. I don't want it to read like book, I want it to be useful and being consistent in such a manner that I can always find my answer quick helps there. Good man pages more or less have this consistency. And because they're terse, it's still quite easy to scan even when the structure for some reason does not conform to the tradition.


I think you misunderstood me; the Index is not the table of contents or the list of headings. The index is what you access with the “i” key, and can also be read directly using the “g” key to go directly to the “Index” node.

I agree, reading headings and navigating that way is mostly a waste of time when trying to find something specific. Which is why I never do it; I use the Index.


KDE also has an interface to GNU Info pages. "info:foo" in Konqueror/Rekonq/etc. and you get hyperlinks and text.

It's probably not nearly as good as emacs, but it's not nearly as bad as info(1).


I'll pile on with an additional anecdote - in 17 years of working almost daily with *nix/BSD systems (and hitting man pages routinely) - I've never once looked at an info page.


Ditto! I have always read man pages. Never read an Info one and I fail to see any need to do so.


Obligatory xkcd

http://xkcd.com/912/


If I want an introduction to complex topic, I usually won't use man pages. I will open up a web browser and search. That will give me web pages that have pictures, diagrams, and possibly even introductory essays about the topic.

There are many more people who know how to write web pages or forum posts than who know how to write "info" pages. There are also great tools for searching the web, but poor tools for search info pages. "info" pages can't even have diagrams or pictures. Consequently, information obtained via "info" tend to be stale, incomplete, and generally unhelpful.

The real question is why "man" pages are still useful in the era of the internet. The answer is that sometimes, you want a concise, accurate, quick reference to what is installed on your system. "man" fills this function admirably. "info" fills that function awkwardly and poorly.


This is true for me too as long as I don't use OpenBSD. The cause is that GNU/Linux manpages are horrible. They are mostly outdated and not in sync with the versions that are actually installed.

As soon as you log in to your newly installed OpenBSD system, your root account has a mail in her mailbox stating to read the "afterboot" manpage. When I first time entered "man afterboot" in my shell, I was blown away.

http://www.openbsd.org/cgi-bin/man.cgi?query=afterboot

  The idea is to create a list of items that can be checked
  off so that you have a warm fuzzy feeling that something
  obvious has not been missed.
It gives you a fast introduction with all informations you need and then references all locations where you find every other topic. At that point, you don't need google anymore where you again find outdated and incorrect informations.

The documentation is so high quality that this is the biggest advantage I appreciate the most.


Yeah. One thing that some people seem to miss is that you can have multiple man pages for a topic-- perhaps one that lays out the general outlines, and one for more specific information.

git does this: it has "man gittutorial" and "gitcvs-migration", as well as man pages for each command. It makes a lot of sense and avoids the "giant wall of irrelevant text" approach.

Bash, on the other hand... yeah. Just try finding anything in there.


An internet search will give me many different choices of documentation of unknown provenance, authorship, official status, datedness, accuracy, and comprehensibility. This, to me, is not helpful, since I have no way of knowing which are any good, even after reading them. On the other hand, Info documentation will give me the official, up-to-date, correct, and mostly well-written documentation.

Internet searches certainly have their place if I want forum posts, mailing lists or blog posts, which I sometimes do. But I often want the official documentation corresponding exactly to my installed version of the software, and this is often harder to find using a web search than simply using the Info documentation, because of the above issues. Also, something to keep in mind in these modern times is that web usage is monitored. Local reading of Info documentation is not.

Tools for searching Info pages are built-in to most Info browsers. I use the Emacs Info browser, which has both the usual Emacs way of searching (C-s and C-r searches both in the current node and in the whole document), and the Info Index, which is what I start with when looking up the reference documentation for something.

Also, contrary to what you claim, Info documentation can and do contain images. For example, the HTML GnuTLS documentation here: (http://gnutls.org/manual/html_node/OpenPGP-certificates.html) was generated from Texinfo, and the images are still there when I browse the corresponding Info documentation with the Emacs Info reader. Those images are simple because they are generated from Dia drawings via EPS files, but images can be anything, just like in HTML.


An internet search will give me many different choices of documentation of unknown provenance, authorship, official status, datedness, accuracy, and comprehensibility.

True. But the documentation for GNU programs, both man and info, is often also "of unknown provenance, authorship, datedness, accuracy, and comprehensibility." You even said yourself that the man pages for many of these GNU programs are years out of date on some systems. Official status is not guaranteed either, since anyone can fork an open source program and produce a clone.

Somehow, despite all that, we manage to muddle on. Probably, it's because we're humans, with the ability to filter out bad information and incomprehensible explanations, and find the real information. And in my experience, this is much easier to do with a man page, which usually simply gets to the point, than with a long, meandering info page which treats me like an idiot and yet often fails to mention vital information.

Thank you for the clarification that info pages can support images. Since I have only ever used info in a terminal, I was not aware of this.

In a lot of ways, info reminds me of Microsoft's CHM format, another HTML workalike with limited abilities. CHM can also support images.

Web usage may be monitored, but I suspect that searching for information about open source programs won't reveal anything about me that downloading Linux did not.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: