> ...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.robin...@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 >