From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout-kit-01.scc.kit.edu (scc-mailout-kit-01.scc.kit.edu [129.13.231.81]) by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id 3deb8080 for ; Mon, 9 Jan 2017 02:42:55 -0500 (EST) Received: from asta-nat.asta.uni-karlsruhe.de ([172.22.63.82] helo=hekate.usta.de) by scc-mailout-kit-01.scc.kit.edu with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (envelope-from ) id 1cQUbU-0007oV-E9; Mon, 09 Jan 2017 08:42:54 +0100 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1cQUbR-0004vP-P7; Mon, 09 Jan 2017 08:42:49 +0100 Received: from athene.usta.de ([172.24.96.10]) by donnerwolke.usta.de with esmtp (Exim 4.84_2) (envelope-from ) id 1cQUbW-0003Zj-12; Mon, 09 Jan 2017 08:42:54 +0100 Received: from localhost (athene.usta.de [local]) by athene.usta.de (OpenSMTPD) with ESMTPA id 10e74ea5; Mon, 9 Jan 2017 08:42:49 +0100 (CET) Date: Mon, 9 Jan 2017 08:42:49 +0100 From: Ingo Schwarze To: Jan Stary Cc: discuss@mdocml.bsd.lv Subject: Re: supporting bzip Message-ID: <20170109074249.GG4271@athene.usta.de> References: <20170109065403.GA13515@www.stare.cz> X-Mailinglist: mdocml-discuss Reply-To: discuss@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170109065403.GA13515@www.stare.cz> User-Agent: Mutt/1.6.2 (2016-07-01) Hi, Jan Stary wrote on Mon, Jan 09, 2017 at 07:54:03AM +0100: > I am using mdocml on other systems beside OpenBSD. > On most linuxes, it works just fine, including gzipped manpages > such as /usr/share/man/man1/ls.1.gz od Debian. > > Now I found myself on a Gentoo linux, where manpages are bzipped, > like /usr/share/man/man1/ls.1.bz2; on this system man(1) displays > what seems to be the verbatim 'bz2' file, unbziped (attached). > See below for the out put of 'man ls'. > > Is it because mdocml does not support bzip? Yes. Neither does it support piping through external unpackers. > If so, should man rather fail than display the page? No. It's a feature that mandoc(1) and man(1) never fail, no matter what the input is. It is a convenience for arbitrary, very serious bugs in otherwise half-sane manuals. I spent a lot of time archieving that feature. It is not a security risk even when you do garbage in - garbage out. It still doesn't write to disk, it still doesn't access arbitrary files, it still doesn't print control codes to the terminal - you see all those harmless question marks in there? > I don't know why any system would bzip it's manpages, > but apparently Gentoo does. Exactly. It is completely stupid nowadays. Just tell them to stop doing such nonsense and install uncompressed. Manual pages are small compared to libraries: schwarze@isnote $ du -sk /usr/share/man 40472 /usr/share/man schwarze@isnote $ du -sk /usr/lib 229516 /usr/lib schwarze@isnote $ du -sk /usr/local/man 50022 /usr/local/man schwarze@isnote $ du -sk /usr/local/lib 2576778 /usr/local/lib That's *uncompressed* mind you, and extensive, high quality OpenBSD manuals. Tell me, which system is unable to afford 100 Megabyte of disk space for manual pages? In this day and age? An embedded system? Right, you certainly have manual pages there. Compressing that stuff just makes life harder for absolutely no benefit whatsoever. > Are there any plans to support bzip beside the ubuquituous gzip? > (I understand if you don't want that in your code.) No plans, and some opposition to trying. Even supporting *.gz is kind of stupid, but that stupidy is widespread enough that i bowed to the pressure. It's implemented in the safest possible way by linking directly against the time proven and no longer much changing libz. I'm very reluctant to resurrect the code to spawn external decompressors - even in portable mandoc. It is messy and potentially risky. So, you want to hear something constructive? Your best option is to just decompress that stuff on your system. (Gentoo is famous for its excessive configurability - maybe there is even an option?) Otherwise, you can set up a small shell script to recursive run bunzip2(1) across the directories in question and run it whenever you are shown garbage after installing new stuff. Bonus: Manuals never get deleted even after uninstalling stuff, so you can still look things up to find out whether it might be worth reinstalling a package that you once had. If you are unable or unwilling to do that, just use a different man(1) implementation and use mandoc(1) the traditional way as a groff drop-in replacement. All you lose that way is apropos(1). Yours, Ingo -- To unsubscribe send an email to discuss+unsubscribe@mdocml.bsd.lv