* 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
* 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).