You are not logged in.
OK, its 5 years later, here are the real stats, if we ARE including info in this debate (since you can use info2man these days) the real winners/losers would go like this, I'm only mentioning the ones mentioned here and the ones I think are the real heavy weights. This question is somewhat dated though now that info pages seem to have absorbed many of the previously big man pages and now they have left behind "smaller versions" of the originals in their man pages, autoconf, for example does this (and so does GCC). So some of these numbers may be off but the man page length is right, here's the dirt:
gcc - 14,302
mplayer - 7,802
fvwm - 7,215
bash - 4,198
cvs - 3,373
wireshark - 2,898
wireshark-filter - 364
zsh - [no man page at all, anymore]
autoconf - 62
vlc - 59
and i threw in the info page's line counts, for good measure (and comparison):
zsh - 34,514
autoconf - 24,889
gcc - 17,572
mplayer - 9,262
fvwm - 9,080
bash - 5,467
cvs - 3,257
wireshark - 3366
wireshark-filter - 413
vlc - 65
So, it looks like GCC is the winner for the man page competition, and zsh is the winner in the
info competition. I hope this helps people who come to this page. I just hate out-of-date information and couldn't resist updating this thread a bit.
(and we all know how -nix information is rapidly changing constantly, so this kind of updating is needed from anyone and everyone!)
NOTE: Command Line Help for VLC is 5,126 lines long (the long version, -H), which does not include the banner, which adds an extra line or two to that.
PS: Just a quick tip, if you are looking this up for programming purposes and are trying for a ballpark figure on sizes of pages you should use when preloading etc, the largest uncompressed man/info page I've com across (to date) is the autoconf page, which is 1144510 bytes (about 1.09 Megabytes) long. In practice you should always anticipate 3-4 times the largest file you can find, my software always uses the x10 rules because I'm paranoid, if anyone ever writes a 10MB man page, i'll be REALLY upset but with info i dont think that will happen. Zsh, for example is HUGE, but is cut up into 5 separate files so the files themselves are not so big.
Last edited by osirisgothra (2013-11-10 10:10:01)
Offline
info page you says:
$ info ponysay | wc -l
5464
That tool is a joke
but they infopage aren't for noobs
I'm currious about 'non-programming programs' whit really long manpages or infopages
Well, I suppose that this is somekind of signature, no?
Offline
zsh - [no man page at all, anymore]
… wat.
% man zsh|wc -l
211
All the best,
-HG
Offline
I believe it was afterboot(8) on OpenBSD. The only thing that kept me from saying "tl;dr" was the fact that I had an insatiable appetite to install a BSD system and FreeBSD struck me as cliche while NetBSD was meant for my toaster. It did help me out quite a bit though, and I did get up and running.
e: I want to get up and going with PKGBUILDs again, but I burned out after reading afterboot(8). I don't think I have the stomach for anything that isn't the glorious ArchWiki.
Last edited by shaunsingh14 (2013-12-11 20:36:52)
I made this account 10 years ago when I was an ignorant and insufferable teenager.
I apologise to all the people I annoyed with my cringe in the past.
Offline
I guess emacs built-in help doesn't count, so...=P
Oh dear, really impressed with wireshark-filter.
Offline
In 2017, we have all man pages in an SQL database for the Arch manual pages repository, so it is easy to find the longest manual page. Here are the top 50 manuals according to the byte length (uncompressed) of the man page source code:
manpages=# select p.repo, p.name as pkgname, m.name, m.section, m.lang, octet_length(m.content) as bytes from archweb_manpages_package as p join archweb_manpages_manpage as m on p.id = m.package_id order by octet_length(m.content) desc limit 50;
repo | pkgname | name | section | lang | bytes
-----------+-----------------------+-----------------------------+---------+-------+---------
community | salt | salt | 7 | en | 7683819
extra | lapack-doc | lapacke.h | 3 | en | 2499878
extra | perl-image-exiftool | Image::ExifTool::TagNames | 3pm | en | 1656141
core | perl | perltoc | 1perl | en | 1216087
core | gcc | gcc | 1 | en | 1134653
multilib | gcc-multilib | g++ | 1 | en | 1134653
multilib | gcc-multilib | gcc | 1 | en | 1134653
core | gcc | g++ | 1 | en | 1134653
community | aarch64-linux-gnu-gcc | aarch64-linux-gnu-gcc | 1 | en | 1134651
community | aarch64-linux-gnu-gcc | aarch64-linux-gnu-g++ | 1 | en | 1134651
community | avr-gcc | avr-g++ | 1 | en | 1133190
community | avr-gcc | avr-gcc | 1 | en | 1133190
community | arm-none-eabi-gcc | arm-none-eabi-gcc | 1 | en | 1133155
community | arm-none-eabi-gcc | arm-none-eabi-g++ | 1 | en | 1133155
extra | ffmpeg | ffmpeg-all | 1 | en | 1131999
extra | ffmpeg | ffserver-all | 1 | en | 1088393
extra | ffmpeg | ffprobe-all | 1 | en | 887212
extra | ffmpeg | ffplay-all | 1 | en | 875226
extra | ffmpeg | ffmpeg-filters | 1 | en | 599611
extra | lapack-doc | doubleOTHERcomputational | 3 | en | 589717
extra | lapack-doc | complexOTHERcomputational | 3 | en | 586927
extra | lapack-doc | complex16OTHERcomputational | 3 | en | 578874
extra | mplayer | mplayer | 1 | ru | 561313
extra | mencoder | mencoder | 1 | ru | 561313
extra | cmake | cmake-modules | 7 | en | 549564
core | perl | perlapi | 1perl | en | 543349
extra | postfix | postconf | 5 | en | 537716
community | mpv | mpv | 1 | en | 527057
extra | scons | scons | 1 | en | 525704
extra | lapack-doc | realOTHERcomputational | 3 | en | 520840
extra | qemu | qemu-qmp-ref | 7 | en | 506930
extra | qemu-headless | qemu-qmp-ref | 7 | en | 506930
core | perl | perlfunc | 1perl | en | 426445
extra | fvwm | fvwm | 1 | en | 413457
extra | samba | smb.conf | 5 | en | 401821
community | collectd | collectd.conf | 5 | en | 396972
extra | mercurial | hg | 1 | en | 391894
core | perl | perldiag | 1perl | en | 391212
extra | mencoder | mencoder | 1 | it | 388878
extra | mplayer | mplayer | 1 | it | 388878
core | s-nail | mail | 1 | en | 380639
extra | mencoder | mencoder | 1 | hu | 377218
extra | mplayer | mplayer | 1 | hu | 377218
extra | mencoder | mencoder | 1 | de | 373761
extra | mplayer | mplayer | 1 | de | 373761
extra | mencoder | mencoder | 1 | fr | 370413
extra | mplayer | mplayer | 1 | fr | 370413
extra | mencoder | mencoder | 1 | zh_CN | 366894
extra | mplayer | mplayer | 1 | zh_CN | 366894
core | perl | Config | 3perl | en | 362705
So it seems that we have an outright winner, the salt(7) manual actually has almost 8 MB! (1.6 MB compressed)
Offline
Hey now, I'm not about to let you take away all the fun! (Though I have to admit an SQL database of Arch's man pages sounds like a really good idea.) Anyway, "biggest" is not always "longest."
■ man perltoc | wc -l
15857
■ man ffmpeg-all | wc -l
23389
$ info ponysay | wc -l 5464
That tool is a joke
If this is in reference to info, I am glad I'm not the only one. If this is in reference to ponysay, we should settle this in the parking lot like men.
Last edited by NoSuck (2017-09-14 03:24:38)
Offline
Anyway, "biggest" is not always "longest."
Sure, that depends on whether you'd like to count blank lines rather than man(7) or mdoc(7) macros in the source code. More generally, the problem with using number of lines as the plain-text document length is that an (almost) blank line contributes the same to the document length as a line with hundreds or thousands of characters.
When it comes to man, note that the ENVIRONMENT section of man(1) says:
MANWIDTH
If $MANWIDTH is set, its value is used as the line length for which manual pages should be formatted. If it is not set, manual pages will be formatted with a line length appropriate to the current terminal (using the value of $COLUMNS, an ioctl(2) if available, or falling back to 80 characters if neither is available). Cat pages will only be saved when the default formatting can be used, that is when the terminal line length is between 66 and 80 characters.
So the favourite measurement method used throughout this thread is environment specific:
$ echo $COLUMNS
274
$ man perltoc | wc -l
15704
$ man ffmpeg-all | wc -l
23148
$ MANWIDTH=80 man perltoc | wc -l
18986
$ MANWIDTH=80 man ffmpeg-all | wc -l
29074
And if we skip blank lines:
$ MANWIDTH=80 man perltoc | sed '/^\s*$/d' | wc -l
16406
$ MANWIDTH=80 man ffmpeg-all | sed '/^\s*$/d' | wc -l
20371
Although ffmpeg-all is still longer in this measure, I'm sure you see how manipulative the "number of lines" measure can be.
Offline
So this thread has really degraded to comparing the size of our MANWIDTHS?
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Even worse, if $MANWIDTH is unset (which I think is the most usual case), it's basically a comparison of $COLUMNS...
Offline
Trilby, considering that it began by considering man lengths, I'd say that it was going to end up there inevitably. I'm just amazed it took nearly ten years to do so.
...and, interestingly, it seems that the lesson of the thread is ultimately "it's not the size that matters, it's how you use it."
Last edited by escondida (2017-09-14 17:38:19)
Offline
Offline