1 |
This is Gentoo 2.2 (4.4.6-gentoo x86_64). |
2 |
The system manpages seem to be bzipped as in |
3 |
/usr/share/man/man1/ls.1.bz2 |
4 |
|
5 |
Why is that? Is there any benefit to compressing the manpages nowadays? |
6 |
IMHO it only adds a layer of complexity, for very questionable benefit |
7 |
(i.e. disk space): how much of the overal system do _manpages_ take? |
8 |
|
9 |
The particular problem I am having is that http://mdocml.bsd.lv/ , |
10 |
my manpage formatter of choice, does deliberately not support bzip |
11 |
(or any other outside decompressors for that matter). |
12 |
|
13 |
Would you please consider distributing plain *.{123456789} manpages |
14 |
and getting rid of the bzip layer? |
15 |
|
16 |
Thank you |
17 |
|
18 |
Jan |
19 |
|
20 |
|
21 |
|
22 |
> I am using mdocml on other systems beside OpenBSD. |
23 |
> On most linuxes, it works just fine, including gzipped manpages |
24 |
> such as /usr/share/man/man1/ls.1.gz od Debian. |
25 |
> |
26 |
> Now I found myself on a Gentoo linux, where manpages are bzipped, |
27 |
> like /usr/share/man/man1/ls.1.bz2; on this system man(1) displays |
28 |
> what seems to be the verbatim 'bz2' file, unbziped (attached). |
29 |
> See below for the out put of 'man ls'. |
30 |
> |
31 |
> Is it because mdocml does not support bzip? |
32 |
|
33 |
Yes. Neither does it support piping through external unpackers. |
34 |
|
35 |
> If so, should man rather fail than display the page? |
36 |
|
37 |
No. It's a feature that mandoc(1) and man(1) never fail, no matter |
38 |
what the input is. It is a convenience for arbitrary, very serious |
39 |
bugs in otherwise half-sane manuals. I spent a lot of time archieving |
40 |
that feature. It is not a security risk even when you do garbage |
41 |
in - garbage out. It still doesn't write to disk, it still doesn't |
42 |
access arbitrary files, it still doesn't print control codes to the |
43 |
terminal - you see all those harmless question marks in there? |
44 |
|
45 |
> I don't know why any system would bzip it's manpages, |
46 |
> but apparently Gentoo does. |
47 |
|
48 |
Exactly. It is completely stupid nowadays. Just tell them to stop |
49 |
doing such nonsense and install uncompressed. Manual pages are small |
50 |
compared to libraries: |
51 |
|
52 |
schwarze@isnote $ du -sk /usr/share/man |
53 |
40472 /usr/share/man |
54 |
schwarze@isnote $ du -sk /usr/lib |
55 |
229516 /usr/lib |
56 |
schwarze@isnote $ du -sk /usr/local/man |
57 |
50022 /usr/local/man |
58 |
schwarze@isnote $ du -sk /usr/local/lib |
59 |
2576778 /usr/local/lib |
60 |
|
61 |
That's *uncompressed* mind you, and extensive, high quality OpenBSD |
62 |
manuals. Tell me, which system is unable to afford 100 Megabyte |
63 |
of disk space for manual pages? In this day and age? An embedded |
64 |
system? Right, you certainly have manual pages there. |
65 |
|
66 |
Compressing that stuff just makes life harder for absolutely no benefit |
67 |
whatsoever. |
68 |
|
69 |
> Are there any plans to support bzip beside the ubuquituous gzip? |
70 |
> (I understand if you don't want that in your code.) |
71 |
|
72 |
No plans, and some opposition to trying. |
73 |
|
74 |
Even supporting *.gz is kind of stupid, but that stupidy is widespread |
75 |
enough that i bowed to the pressure. It's implemented in the safest |
76 |
possible way by linking directly against the time proven and no |
77 |
longer much changing libz. I'm very reluctant to resurrect the |
78 |
code to spawn external decompressors - even in portable mandoc. |
79 |
It is messy and potentially risky. |
80 |
|
81 |
|
82 |
So, you want to hear something constructive? Your best option is to |
83 |
just decompress that stuff on your system. (Gentoo is famous for |
84 |
its excessive configurability - maybe there is even an option?) |
85 |
Otherwise, you can set up a small shell script to recursive run |
86 |
bunzip2(1) across the directories in question and run it whenever |
87 |
you are shown garbage after installing new stuff. Bonus: Manuals |
88 |
never get deleted even after uninstalling stuff, so you can still |
89 |
look things up to find out whether it might be worth reinstalling |
90 |
a package that you once had. |
91 |
|
92 |
If you are unable or unwilling to do that, just use a different |
93 |
man(1) implementation and use mandoc(1) the traditional way as a |
94 |
groff drop-in replacement. All you lose that way is apropos(1). |
95 |
|
96 |
Yours, |
97 |
Ingo |