Re: implement .so

[Ingo Schwarze <schwarze@usta.de>]

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