* Behaviour of .so differs between mandoc and groff @ 2023-04-22 4:21 Alexis 2023-04-29 23:24 ` Alexis 0 siblings, 1 reply; 6+ messages in thread From: Alexis @ 2023-04-22 4:21 UTC (permalink / raw) To: discuss, groff, man-db-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Behaviour of .so differs between mandoc and groff 2023-04-22 4:21 Behaviour of .so differs between mandoc and groff Alexis @ 2023-04-29 23:24 ` Alexis [not found] ` <20230430120555.3mydcm7qmbsf75v6@illithid> 0 siblings, 1 reply; 6+ messages in thread From: Alexis @ 2023-04-29 23:24 UTC (permalink / raw) Cc: discuss, groff, man-db-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <20230430120555.3mydcm7qmbsf75v6@illithid>]
* Re: Behaviour of .so differs between mandoc and groff [not found] ` <20230430120555.3mydcm7qmbsf75v6@illithid> @ 2023-05-03 0:27 ` Alexis 2023-05-04 5:44 ` Alexis 1 sibling, 0 replies; 6+ messages in thread From: Alexis @ 2023-05-03 0:27 UTC (permalink / raw) To: G. Branden Robinson; +Cc: discuss, groff, man-db-devel "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Behaviour of .so differs between mandoc and groff [not found] ` <20230430120555.3mydcm7qmbsf75v6@illithid> 2023-05-03 0:27 ` Alexis @ 2023-05-04 5:44 ` Alexis 2023-05-04 6:18 ` Jan Stary 1 sibling, 1 reply; 6+ messages in thread From: Alexis @ 2023-05-04 5:44 UTC (permalink / raw) To: discuss, groff, man-db-devel "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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Behaviour of .so differs between mandoc and groff 2023-05-04 5:44 ` Alexis @ 2023-05-04 6:18 ` Jan Stary 2023-05-04 7:13 ` Alexis 0 siblings, 1 reply; 6+ messages in thread From: Jan Stary @ 2023-05-04 6:18 UTC (permalink / raw) To: discuss; +Cc: groff, man-db-devel > > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Behaviour of .so differs between mandoc and groff 2023-05-04 6:18 ` Jan Stary @ 2023-05-04 7:13 ` Alexis 0 siblings, 0 replies; 6+ messages in thread From: Alexis @ 2023-05-04 7:13 UTC (permalink / raw) To: discuss; +Cc: groff, man-db-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-05-04 7:21 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-04-22 4:21 Behaviour of .so differs between mandoc and groff Alexis 2023-04-29 23:24 ` Alexis [not found] ` <20230430120555.3mydcm7qmbsf75v6@illithid> 2023-05-03 0:27 ` Alexis 2023-05-04 5:44 ` Alexis 2023-05-04 6:18 ` Jan Stary 2023-05-04 7:13 ` Alexis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).