52

Is there a reason why most man pages don't include a few common examples? They usually explain all the possible options, but that makes it even harder for a beginner to understand how it's "usually" used.

  • 1
    My guess is that they wanted to save valuable disk space, like with getting rid of the the CR. Cf. Beckett, Watt, p.8: "Much valuable space has been saved [...] by avoidance of the plethoric reflexive pronoun after say." – Peter A. Schneider Aug 29 '16 at 15:14
  • 3
    One attempted workaround for this problem is tldr-pages.github.io, though I don't see why they make it easy to download everything up front for offline access. – Nathan Long Aug 29 '16 at 20:16
  • man jq has over 1000 lines of examples (on Ubuntu 16.04) – Motte001 Sep 7 '16 at 16:12
49

That depends on the man pages... Traditionally, they have included a section with examples - but for some reason that is usually missing from the man pages under Linux (and I assume other using GNU commands - which are most these days). On Solaris on the other hand, almost every man page include the Example section, often with several examples.

If I were to guess, FSF/GNU has for a long time discouraged use of man pages and prefer users to use info for documentation instead. info pages tend to be more comprehensive than man pages, and usually do include examples. info pages are also more "topical" - i.e. related commands (eg. commands for finding files) can often be found together.

Another reason may be that GNU and its man pages are used on many different operating systems which may differ from each other (there are after all lots of differences just between different Linux distros). The intention may have been that the publisher added examples relevant to the particular OS/distro - which obviously is rarely done.

I would also add that man pages were never intended to "teach beginners". UNIX was developed by computer experts (old term "hackers") and intended to be used by computer experts. The man pages were thus not made to teach a novice, but to quickly assist a computer expert who needed a reminder for some obscure option or strange file format - and this is reflected in how a man page is sectioned.

man-pages are thus intended as

  • A quick reference to refresh your memory; showing you how the command should be called, and listing available options.
  • A deep and thorough - and usually very technical - description of all aspects of the command. It's written by computer experts, for fellow computer experts.
  • List of environment variables and files (i.e. config files) used by the command.
  • Reference to other documentation (eg. books), and other man pages - eg. for the format of config files and related/similar commands.

That said, I very much agree with you that man pages ought to have examples, since they can explain the usage better than wading through the man page itself. Too bad examples generally aren't available on Linux man pages...

Sample of the Example part of a Solaris man page - zfs(1M):

(...)
EXAMPLES
     Example 1 Creating a ZFS File System Hierarchy

     The following commands create a filesystem named  pool/home
     and  a  filesystem  named  pool/home/bob.  The mount point
     /export/home is set for  the  parent  filesystem,  and  is
     automatically inherited by the child filesystem.

       # zfs create pool/home
       # zfs set mountpoint=/export/home pool/home
       # zfs create pool/home/bob

     Example 2 Creating a ZFS Snapshot

     The following command creates a  snapshot  named  yesterday.
     This  snapshot  is  mounted  on  demand in the .zfs/snapshot
     directory at the root of the pool/home/bob file system.

       # zfs snapshot pool/home/bob@yesterday

     Example 3 Creating and Destroying Multiple Snapshots

     The following command creates snapshots named  yesterday  of
     pool/home  and  all  of  its  descendent  file systems. Each
     snapshot is mounted on demand in the .zfs/snapshot directory
     at  the root of its file system. The second command destroys
     the newly created snapshots.

       # zfs snapshot -r pool/home@yesterday
       # zfs destroy -r pool/home@yesterday

SunOS 5.11          Last change: 23 Jul 2012                   51

System Administration Commands                            zfs(1M)

     Example 4 Disabling and Enabling File System Compression

     The following command disables the compression property  for
(...)

This particular man page comes with 16(!) such examples... Kudos to Solaris!
(And I'll admit I myself have mostly followed these examples, instead of reading the whole man page for this command...)

  • 2
    That last sentence highlights a problem with having examples in manuals. One takes the examples that best fits one's needs without fully understanding the implications of the particular application of the tool. And later, one can just say "I did it like this", but not really why or what it meant. – Kusalananda Aug 29 '16 at 9:23
  • 6
    @Kusalananda In my defense, I have read about the various options and about the sub-commands I've actually needed - just not the whole thing (yet). It's simply not relevant for my use... Despite the danger of misuse, examples do serve a purpose - and if all you need is just the most basic usage of a command, reading about all the bells and whistles are hardly necessary. – Baard Kopperud Aug 29 '16 at 13:03
  • @Kusalananda It might also depend on the commands. Most Unix and GNU utils I know are well documented, but you need the documentation to do anything sensible. The newer Solaris commands (especially zfs) are designed pretty naturally. For example, zfs destroy pool/filesystem is basic usage and fine for 90% of use cases. Short options like -r for recursive are more special and need consultation before use, because they might have unintended side-effects. – user121391 Aug 30 '16 at 11:30
26

I don't think there's a good answer to this. It's a culture thing. Some man pages do have example usage. E.g. man rsync. You could try to change the culture by writing to the man page author and asking him or her to add some sample usage or (much better) offering some sample usage examples yourself. If you offer a free software author a patch, particularly a documentation patch, it's approximately ten thousand times more likely to achieve the desired result than a simple request.

7

It depends:

  • most of the programs that you would find interesting are developed over a period of time, initially to solve a problem and later to improve the solution. The developers of the programs explain what they thought was important to know (and documentation was not the problem they were solving).
  • for some programs, the developers prefer to provide sample programs or scripts which show how to use a given program (or library). Again, this is done to solve a problem: making the program easier to test.

    Some of the examples may be based on bug reports from users, and when short finds a place in the manual. Lengthy examples are rarely provided in manuals, and short examples have the problem that they tend to be trivial, repetitive and not really providing the user as much insight as a well organized description of the way a program works.

  • in some cases you'll find documentation which is provided by others not involved in the development process. That is, the developers did not participate except for reviewing the documentation. That sort of effort can be disregarded.
  • 5
    "That sort of effort can be disregarded." I'm not sure what this means. – Faheem Mitha Aug 28 '16 at 14:41
  • The documentation doesn't contribute anything useful when it's not based on experience. – Thomas Dickey Aug 28 '16 at 18:13
  • In fact documentation not based on experience can make a negative contribution - i.e. it's just plain wrong. – alephzero Aug 28 '16 at 20:54
  • Sure - I mentioned it because some of the examples which OP undoubtedly has in mind fall into this category (I'll refrain from providing a list on this forum). – Thomas Dickey Aug 28 '16 at 20:59
  • 2
    @ThomasDickey. I completely disagree with this assessment. The ability to write a utility does not necessarily come with the ability to explain the API to an end user. T – chiggsy Aug 29 '16 at 13:54
6

If you're looking for an alternative to man pages, you could always try bro pages, which only show various examples to a command, which you can then vote on among a list of community-submitted examples. For example, the command bro tar will give you:enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.