Hallo Ingo, Ingo Schwarze <schwa...@usta.de> wrote: [.] |Unfortunately, your example is broken in multiple ways and can |hardly be amended to make it work, so it doesn't demonstrate
True. (But what i did for testing was ?0[]$ groff -mdoc -Tutf8 xwhat.1 2>/dev/null and it works -- in fact i've chosen what.1 because it is the smallest manual page i got my fingers at fast. Sorry. :) You know, i don't want to become overly bugging, but in my humble opinion, especially as a library designer, it must be said that problems that are not solved at deep levels become overly complicating and expensive, if at all possible to solve at a higher level. This is part of the beauty of Unix, with open(2), but especially with *read*(2), *write*(2), select(2) and close(2). On each side of these interfaces there is an enormous amount of complexity, and increasing, but here we have a few "simple" system calls and they drive the whole thing, efficiently. So for this here.. i think Matthew Dillon had a great idea and with some nice object oriented programming it will become possible to add support for file decompression at the lowest possible level regarding troff. For this to happen only a few lines of code have to be added to an already existing path test, if i don't count the object-encapsulation, which is a patch by itself; and of course not using external decompressor programs but libraries is yet another patch on top of that, but that is something different again. In effect this change on the (GNU) troff(1) side, and i'm wildly guessing that exactly this is what Matthew Dillon had in mind, (and should i have Cc:'d him at first glance? Ooops.) can and will reduce the overall complexity of the toolchain that is used for displaying manual pages. [.] |Using .so in manuals is a terrible idea in the first place. |The only application that sort-of works half of the time is as a |poor man's replacement of ln(1), like X.org deplorably uses it. Ok. But on the other hand, if there are filesystems which use available storage in the file's management structure not only for symlink-, but also for regular content then i do not actually see the difference. I personally would favour the `.so' request. On the other hand people start using linker scripts instead of simple symbolic links for dynamic libraries, which i don't like, and which thus reveals that my opinions in this area are a bit schizophrenic. --steffen
