From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp1.rz.uni-karlsruhe.de (Debian-exim@smtp1.rz.uni-karlsruhe.de [129.13.185.217]) by krisdoz.my.domain (8.14.3/8.14.3) with ESMTP id o9OJfWLO024570 for ; Sun, 24 Oct 2010 15:41:33 -0400 (EDT) Received: from hekate.usta.de (asta-nat.asta.uni-karlsruhe.de [172.22.63.82]) by smtp1.rz.uni-karlsruhe.de with esmtp (Exim 4.63 #1) id 1PA6Re-0001BT-Mm; Sun, 24 Oct 2010 21:41:30 +0200 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.71) (envelope-from ) id 1PA6Re-0002fJ-LR for tech@mdocml.bsd.lv; Sun, 24 Oct 2010 21:41:30 +0200 Received: from iris.usta.de ([172.24.96.5] helo=usta.de) by donnerwolke.usta.de with esmtp (Exim 4.69) (envelope-from ) id 1PA6Re-0005mo-Kc for tech@mdocml.bsd.lv; Sun, 24 Oct 2010 21:41:30 +0200 Received: from schwarze by usta.de with local (Exim 4.71) (envelope-from ) id 1PA6Re-00051c-99 for tech@mdocml.bsd.lv; Sun, 24 Oct 2010 21:41:30 +0200 Date: Sun, 24 Oct 2010 21:41:30 +0200 From: Ingo Schwarze To: tech@mdocml.bsd.lv Subject: Re: implement .so Message-ID: <20101024194129.GJ20876@iris.usta.de> References: <20101024164057.GF20876@iris.usta.de> <20101024164945.GA25275@britannica.bec.de> <20101024172914.GH20876@iris.usta.de> <20101024173857.GA18657@britannica.bec.de> <20101024180019.GI20876@iris.usta.de> <20101024181502.GA13039@britannica.bec.de> X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101024181502.GA13039@britannica.bec.de> User-Agent: Mutt/1.5.20 (2009-06-14) Hi Joerg, Joerg Sonnenberger wrote on Sun, Oct 24, 2010 at 08:15:02PM +0200: > On Sun, Oct 24, 2010 at 08:00:19PM +0200, Ingo Schwarze wrote: >> * It would need to be done for both ports and Xenocara. >> * It would need to be done in each operating and ports system >> using mandoc; on a medium term, that may amount to at least >> four systems (OpenBSD, NetBSD, FreeBSD, DragonFly BSD). > Having a single script like soelim (or whatever you want to call it) > minimizes the redundancy. It should be trivial to hook up in any of the > above systems. Attached is an AWK script that prints the link target to > stdout if it unique or returns failure otherwise. Shouldn't be hard to > polish so that it takes a list of files in stdin and does the magic, > potentially including things like using zcat etc. I just talked to espie@ (who is maintaining our ports system) and he confirmed that a solution of this kind would not be difficult in our ports system. But he does consider it clunky and would prefer having a mandoc .so implementation. In addition to my remark that .so is rather a roff than a build system feature, he said "Why rely on a partial workaround in the wrong place when a full solution in the right place is easy to implement?" Indeed, i'm not expecting .so to require much code. Besides, Marc made the point that if we want to convince people to accept mandoc as a standard implementation for formatting manuals, we will almost certainly need .so support anyway: Not everyone will agree that is useless, if even among ourselves we are not 100% sure, so we risk fruitless and distracting discussions whether mandoc is complete or defective. Regarding Xenocara, matthieu@ obviously strongly prefers a mandoc solution to a solution in the build system as well. If i understand correctly, that is in particular because the X.org build system is already rather entangled and every additional bit of complexity adds to the pain. So, i'm definitely willing to get those discussions off the table by just implementing the feature myself; provided the code will be small, clean and local (and maintained by me), would you still be opposed in principle to putting it in? >> * From a maintenance perspective, .so does not seem that bad: >> it's strictly local in main.c without tentacles into any libs. >> * It would also put the code where it belongs: .so is a roff >> feature, not a build system feature. > Actually, there are a number of useful cases where you have to fix it > up already. Consider using compressed man pages by default. > That breaks badly with .so. Indeed, i don't expect we want to link against zlib. So, such special needs would still need to be handled outside mandoc - but only by those systems wanting them. >> * All people i'm asking tend to say i should not worry that >> much about the my security concerns, maybe i'm indeed >> excessively paranoid in that respect. > Allow path names relative to the current directory and with /../ > in them. Hm? Sorry? I definitely need to allow path names relative to the current dir. That's used all over the place. You mean, i should *not* allow absolute path names, and i should not allow pathnames with ../ in them? Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv