Hi all, On my Gentoo system, awk.1 simply contains an .so request whose argument is the man page for the actual awk implementation in use, i.e. just: .so gawk.1 However, although this works when using man-db, it doesn't when one is using mandoc instead, as on my system. Instead of gawk.1 being sourced, processed and displayed, i get output along the lines of: () () See the file gawk.1. () However, if i change the request in awk.1 to: .so man1/gawk.1 then everything works as expected. The example in the entry for .so in mandoc_roff(7) is what led me to try the preceding, but there's no further indication that the requirement for a leading section directory is consciously different from any other roff implementation, or from groff in particular. A comment in roff_so() in mandoc/roff.c[a] says: /* /* Handle `so'. Be EXTREMELY careful, as we shouldn't be * opening anything that's not in our cwd or anything beneath * it. Thus, explicitly disallow traversing up the file-system * or using absolute paths. */ i couldn't find any discussion about .so in the mandoc TODO list[b]. i've no idea what the 'correct' behaviour 'should' be, from whatever perspective (historical / security / groff-compatibility / etc.), so am cross-posting to what i believe to be the relevant lists. Alexis. [a] https://cvsweb.bsd.lv/mandoc/roff.c?rev=1.395&content-type=text/x-cvsweb-markup [b] https://cvsweb.bsd.lv/mandoc/TODO?rev=1.327&content-type=text/x-cvsweb-markup -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Ping. Does anyone have any thoughts on this? It's a small but
persistent irritation on my system. :-)
Alexis <flexibeast@gmail.com> writes:
> [1. text/plain]
>
> Hi all,
>
> On my Gentoo system, awk.1 simply contains an .so request whose
> argument is the man page for the actual awk implementation in
> use,
> i.e. just:
>
> .so gawk.1
>
> However, although this works when using man-db, it doesn't when
> one is
> using mandoc instead, as on my system. Instead of gawk.1 being
> sourced, processed and displayed, i get output along the lines
> of:
>
> () ()
> See the file gawk.1.
>
>
> ()
>
> However, if i change the request in awk.1 to:
>
> .so man1/gawk.1
>
> then everything works as expected.
>
> The example in the entry for .so in mandoc_roff(7) is what led
> me to
> try the preceding, but there's no further indication that the
> requirement for a leading section directory is consciously
> different
> from any other roff implementation, or from groff in
> particular. A
> comment in roff_so() in mandoc/roff.c[a] says:
>
> /*
> /* Handle `so'. Be EXTREMELY careful, as we shouldn't be
> * opening anything that's not in our cwd or anything beneath
> * it. Thus, explicitly disallow traversing up the
> file-system
> * or using absolute paths.
> */
>
> i couldn't find any discussion about .so in the mandoc TODO
> list[b].
>
> i've no idea what the 'correct' behaviour 'should' be, from
> whatever
> perspective (historical / security / groff-compatibility /
> etc.), so
> am cross-posting to what i believe to be the relevant lists.
>
>
> Alexis.
>
> [a]
> https://cvsweb.bsd.lv/mandoc/roff.c?rev=1.395&content-type=text/x-cvsweb-markup
>
> [b]
> https://cvsweb.bsd.lv/mandoc/TODO?rev=1.327&content-type=text/x-cvsweb-markup
--
To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
"G. Branden Robinson" <g.branden.robinson@gmail.com> writes: > In practice, as I understand it, `so` doesn't achieve anything > for man > pages that can't be done with symbolic links and (importantly) a > man > page indexer that is symlink-aware. Perhaps `so` support was > preserved, > and its practice retained, for a long time because at one point > in the > 1980s I think there was an AT&T/BSD split over symbolic links > even being > supported by the kernel. (And, to be fair, symbolic links are > something > of a hack that can make file system operations more painful. I > see from > the nftw() man page that they were still doing so as late as > glibc 2.30, > 3 years ago.) > > Does this help? Thanks, i've just opened a bug on the Gentoo bug tracker about this, "man pages for alternatives: Use of .so instead of symlink creates issue when using mandoc": https://bugs.gentoo.org/905624 in which i reference this thread. Alexis. -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
"G. Branden Robinson" <g.branden.robinson@gmail.com> writes: > In practice, as I understand it, `so` doesn't achieve anything > for man > pages that can't be done with symbolic links and (importantly) a > man > page indexer that is symlink-aware. Perhaps `so` support was > preserved, > and its practice retained, for a long time because at one point > in the > 1980s I think there was an AT&T/BSD split over symbolic links > even being > supported by the kernel. (And, to be fair, symbolic links are > something > of a hack that can make file system operations more painful. I > see from > the nftw() man page that they were still doing so as late as > glibc 2.30, > 3 years ago.) mgorny@gentoo.org has just pointed out that: > The problem with symlinks is that they need to be updated to > match manpage compression. `.so` works with any compression > used for the manpage. -- https://bugs.gentoo.org/905624#c1 On Gentoo, man page compression is affected by user-specified values for PORTAGE_COMPRESS and PORTAGE_COMPRESS_EXCLUDE_SUFFIXES; PORTAGE_COMPRESS is set to 'bzip2' by default. Alexis. -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
> > The problem with symlinks is that they need to be updated to match
> > manpage compression. `.so` works with any compression used for the
> > manpage.
That's not a problem with symlinks,
but a problem with manpage compression.
Why would anyone compress manpages?
How much space does that save overall?
OpenBSD:
43.6M /usr/share/man/
36.6M /usr/local/man/
17.4M /tmp/man.tar.gz
macOS:
133M /Library/Developer//CommandLineTools/SDKs/MacOSX13.3.sdk/usr/share/man
25M /usr/share/man/
57M /tmp/man.tar.gz
Tens of megabytes saved, in the whole system.
Absoultely not worth the hassle.
--
To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv
Jan Stary <hans@stare.cz> writes: > That's not a problem with symlinks, > but a problem with manpage compression. > > Why would anyone compress manpages? > How much space does that save overall? [snip example] > Tens of megabytes saved, in the whole system. > Absoultely not worth the hassle. i personally agree, but here's a discussion i opened on the Gentoo bug tracker about the compression of man pages in the context of using mandoc rather than man-db: https://bugs.gentoo.org/836367 in which i linked to this old thread on mandoc-discuss: https://marc.info/?l=mandoc-discuss&m=160666427213578&w=2 and in particular Ingo's comment: https://marc.info/?l=mandoc-discuss&m=160668087317110&w=2 (This is all a result of my stubborn insistence on using mandoc on Gentoo. :-) ) Alexis. -- To unsubscribe send an email to discuss+unsubscribe@mandoc.bsd.lv