Re: "make check" failing on macOS (was: macOS Terminal man page URL format)

[John Gardner]

>
> I just want to compare 2 byte streams in a shell script without using
> temporary files.


Just out of curiosity: why? The test directory is already polluted with
artefacts during the course of the test-run: I don't see why creating a few
more is burdensome.

In any case, the difference between GNU od(1) and BSD od(1) is that the
latter preserves trailing whitespace:

GNU:
│0x00000000│ 30 30 30 30 30 30 30 20 20 20 41 20 20 5C 62 20 │0000000   A
 \b │
│0x00000010│ 20 20 42 20 20 5C 62 20 20 20 43 20 20 20 20 20 │  B  \b   C
  │
│0x00000020│ 20 20 44 20 20 5C 6E 0A 30 30 30 30 30 31 30    │  D
 \n.0000010 │

BSD:
│0x00000000│ 30 30 30 30 30 30 30 20 20 20 20 41 20 20 5C 62 │0000000    A
 \b│
│0x00000010│ 20 20 20 42 20 20 5C 62 20 20 20 43 20 20 20 20 │   B  \b   C
   │
│0x00000020│ 20 20 20 44 20 20 5C 6E 20 20 20 20 20 20 20 20 │   D  \n
   │
│0x00000030│ 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 │
   │
│0x00000040│ 20 20 20 20 20 20 20 20 0A 30 30 30 30 30 31 30 │
 .0000010│

Ergo, simply appending ` *` to your grep(1) expression should be enough to
accommodate both flavours.

On Sat, 11 Feb 2023 at 12:23, G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> Hi John,
>
> At 2023-02-11T10:19:08+1100, John Gardner wrote:
> > Yes, it builds successfully now (macOS 12.6.3). I ran `make install`
> > and the installed Groff seems to be working perfectly.
>
> Excellent!
>
> > However, when I ran `make check` in my checkout directory, 7 of the
> > tests failed (full details in the attached log file):
> [...]
> > Are these normal?
>
> Certainly not.
>
> > I'm attaching my build logs just in case.
>
> Thank you--this is helpful.  Some or all of these problems I think we
> have seen on macOS before; they involve the portability of shell syntax
> and of a few (incompletely) standardized tools.  xooglers "just want to
> serve 5 terabytes".  I just want to compare 2 byte streams in a shell
> script without using temporary files.  Astoundingly, this is way harder
> and system-dependent than it should be.  I attribute that to the early
> mentality that the PDP-11 was the only machine that mattered, and the
> belief of the succeeding generation, despite obvious contrary evidence,
> that the VAX was the only machine that mattered.
>
> Nowadays, we laugh at the blinkered folly of our ancestors and
> confidently understand that x86-64 is all that matters.
>
> > FAIL: src/roff/groff/tests/some_escapes_accept_newline_delimiters.sh
>
> "od -t c".  If I remember correctly, macOS od produces output unlike
> both Unix Version 7 od and GNU od.  Certainly macOS and GNU od don't
> agree with each other.
>
> > FAIL: tmac/tests/an_TS-adds-no-vertical-space.sh
>
> sed.  I'll have to look up what hoop is required for macOS sed, which I
> think comes from one of the BSDs but, as I recall, proudly refuses to
> admit any means of identifying itself by version number in execution.
> (That's for disgusting things like GNU programs.)
>
> > FAIL: tmac/tests/an_use-input-traps-correctly.sh
>
> This looks like a shell difference in how sequences of backslashes are
> interpreted in double-quoted strings.  I see no variable interpolations
> in the cases in question, so I may be able to fix this by just making
> the strings single-quoted.
>
> > FAIL: tmac/tests/doc_heading-font-remapping-works.sh
>
> sed again.  It seems to think I am using GNU extensions, but I'm not
> using any marked as such in GNU sed's man page.  Maybe it's a BRE vs.
> ERE thing.  POSIX prescribes a -E option for this.  I'm sure the sed on
> Solaris 10 doesn't support it.  :-|
>
> > FAIL: tmac/tests/latin2_works.sh
> > FAIL: tmac/tests/latin5_works.sh
> > FAIL: tmac/tests/latin9_works.sh
>
> "od -t c" again.
>
> This is useful information, even if it fuels my frustration with
> vendors of fundamental Unix utilities.  I'll see what I can do.
>
> Regards,
> Branden
>