discuss@mandoc.bsd.lv
 help / color / mirror / Atom feed
* 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).