Re: macOS Terminal man page URL format

[John Gardner]

> ...wait.  Did you configure your groff build to use one of the terminal
> devices as the default typesetter?  Or maybe you have GROFF_TYPESETTER
> set a terminal device in the environment?

I do, actually
<https://github.com/Alhadis/.files/blob/bee70cfd0d9a2343b68fe83d61967610b3e66f9d/env.sh#L59>.
It's set to utf8, which has historically been necessary on macOS to enable
UTF-8 characters in man pages.

> If that starts dinging the bell, then what I need to do is add a "-T ps"
argument to these tests.

Or unset/override pertinent environment variables before running the tests,
which is How I'd Do It™.

On Thu, 16 Feb 2023 at 15:30, G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> Hi John,
>
> At 2023-02-16T15:09:06+1100, John Gardner wrote:
> > Many thanks. All but one of the tests are passing now, which is the
> > same one you're having troubles reproducing the failure of:
> >
> > > > FAIL: tmac/tests/an_use-input-traps-correctly.sh
> > >
> > > I found this very weird but I could not reproduce this test failure on
> a
> > > macOS system.
> >
> > I've logged the contents of the $output variable for each failing test
> > (something that I expected to be included in test-suite.log, but
> > isn't):
>
> ...I haven't been entirely consistent about doing that.  I don't think
> it's always appropriate, since some tests can produce a lot of output.
>
> > checking that SM macro uses correct input trap 'it'
> > ...FAILED
> >
> > <beginning of page>
> > foo(1) General Commands Manual foo(1)
> > 1010
> > groff test suite 2022-06-07 foo(1)
> >
> > checking that SB macro uses correct input trap 'it'
> > ...FAILED
> >
> > <beginning of page>
> > foo(1) General Commands Manual foo(1)
> > B10R10
> > groff test suite 2022-06-07 foo(1)
>
> Okay, so here's what the sources of those tests look like.
>
> --snip--
> # SM
>
> input=".TH foo 1 2022-06-07 \"groff test suite\"
> .SM \\\\n[.s]\c
> \\n[.s]"
>
> output=$(printf "%s\n" "$input" | "$groff" -man -a 2>&1)
>
> echo "checking that SM macro uses correct input trap 'it'" >&2
> echo "$output" | grep -Fqx '910' || wail
>
> # SB
>
> input=".TH foo 1 2022-06-07 \"groff test suite\"
> .SB \\\\n[.fn]\\\\n[.s]\c
> \\n[.fn]\\n[.s]"
>
> output=$(printf "%s\n" "$input" | "$groff" -man -a 2>&1)
>
> echo "checking that SB macro uses correct input trap 'it'" >&2
> echo "$output" | grep -Fqx 'TB9TR10' || wail
> --end snip--
>
> What we're doing is telling the formatter to embed the type size (in
> points) and, in the second test, the groff font name as well into the
> output.
>
> groff(7) says:
>     \n[.s]         Type size in points as a decimal fraction (string‐
>                    valued).  see .ps and \s.
>     \n[.fn]        Resolved name of selected font (string‐valued); see
>                    .ft and \f.
>
> Here is a grid summarizing the situation.
>
> test | expected output | your output
> SM   | 910             | 1010
> SB   | TB9TR10         | B10R10
>
> That's quite bizarre.  So let's look at the macros themselves next.
>
> --snip--
> .\" Set arguments (or next input line producing written or drawn output
> .\" if none) at smaller type size.
> .de1 SM
> .  it 1 an-input-trap
> .  ps -1
> .  if \\n[.$] \&\\$*
> ..
> .
> .\" Set arguments (or next input line producing written or drawn output
> .\" if none) in bold style at smaller type size.
> .de1 SB
> .  it 1 an-input-trap
> .  ps -1
> .  ft B
> .  if \\n[.$] \&\\$*
> ..
> --end snip--
>
> So, it's like type size changes are being outright refused, and font
> families utterly ignored.  Those are things only nroff devices do...
>
> ...wait.  Did you configure your groff build to use one of the terminal
> devices as the default typesetter?  Or maybe you have GROFF_TYPESETTER
> set a terminal device in the environment?
>
> If that starts dinging the bell, then what I need to do is add a "-T ps"
> argument to these tests.
>
> Regards,
> Branden
>