bugGNU roff - Bugs: bug #62357, [build] tests using "locale...

 
 

bug #62357: [build] tests using "locale charmap" skipped on macOS

Submitter:  John Gardner <alhadis>
Submitted:  Sun 24 Apr 2022 02:08:08 PM UTC
   
 
Category:  Driver - others/general Severity:  3 - Normal
Item Group:  Test Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 21 May 2022 04:18:39 PM UTC, comment #18: 


commit e197762252f0dd75f50fd3a50e0273b812ec5793
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Fri May 20 05:14:11 2022 -0500

    [tests]: Fix "od -c" portability problem.

    * src/devices/grotty/tests/basic_latin_glyphs_map_correctly.sh: Fix
      portability problem: POSIX says that "od -c" (and "od -t c") are
      supposed to emit printing characters as defined by the underlying
      locale, but GNU coreutils od doesn't do this and macOS od does.  Set
      `LC_ALL` to "C" when running it to force 3-digit octal reporting of
      characters with their eighth bit set.

    Fixes <https://savannah.gnu.org/bugs/?62357>.  Thanks to John
    Gardner for the report.  Also see <https://pubs.opengroup.org/\
    onlinepubs/9699919799/utilities/od.html>.


G. Branden Robinson <gbranden>
Group administrator
Fri 20 May 2022 10:00:57 AM UTC, comment #17: 

Good deal!  Thanks, John.

G. Branden Robinson <gbranden>
Group administrator
Fri 20 May 2022 09:14:53 AM UTC, comment #16: 

comment #15:

> Please try the attached patch and let me know if the test passes after applying it.


That seemed to do the trick! I've attached the build log.

(BTW, I remembered I still had a /usr/local/share/groff from a previous installation of an earlier build. I gave it the ol' rimraf (in case it was skewing the test results somehow) before realising that it would've been wiser to wipe them after confirming that your patch worked…)

(file #53235, file #53236)

John Gardner <alhadis>
Fri 20 May 2022 08:22:42 AM UTC, comment #15: 

Hi John,

Please try the attached patch and let me know if the test passes after applying it.

Since I'm still puzzled about the "SKIP" results, you might need to try it after cleaning the tree.  "make -j check" should do the build and the tests.

(file #53234)

G. Branden Robinson <gbranden>
Group administrator
Fri 20 May 2022 07:12:24 AM UTC, comment #14: 

comment #11:

> The problem is a divergence between Linux 'od -c' output and macOS (BSD?) 'od -c' output.  Except I haven't heard any complaints from Ingo, so this may be a true macOS-ism.


This might make your life easier:

https://opensource.apple.com/source/shell_cmds/shell_cmds-216.60.1/hexdump/ (Source code for od(1), as well as its man page).

You can find the source to other macOS commands at https://opensource.apple.com/source/. Unsurprisingly, they don't disclose the source to programs that were never freely-licensed to begin with… but that's unlikely to ever concern a non-macOS user.

John Gardner <alhadis>
Fri 20 May 2022 05:31:47 AM UTC, comment #13: 

Nope, I'm wrong.

In the test, I'm using "od -t c", not "od -c".  The GNU od(1) man pages says these are the synonymous...

>        -c     same as -t c,  select printable characters or backslash escapes


...but they're not supposed to be.  Its GNU Info node


info '(coreutils) od invocation'


makes the same claim.  So it is apparently GNU that is out of POSIX conformance here.  Here's what Issue 8 says about "od -t c".

> The type specifier character c specifies that bytes shall be interpreted as characters specified by the current setting of the LC_CTYPE locale category. Characters listed in the table in XBD File Format Notation ( '\\', '\a', '\b', '\f', '\n', '\r', '\t', '\v' ) shall be written as the corresponding escape sequences, except that <backslash> shall be written as a single <backslash> and a NUL shall be written as '\0'. Other non-printable characters shall be written as one three-digit octal number for each byte in the character. Printable multi-byte characters shall be written in the area corresponding to the first byte of the character; the two-character sequence "**" shall be written in the area corresponding to each remaining byte in the character, as an indication that the character is continued. When either the -j skip or -N count option is specified along with the c type specifier, and this results in an attempt to start or finish in the middle of a multi-byte character, the result is implementation-defined.


After giving BSD/Apple partisans a moment to ventilate their indignation at my error, it seems I must use "od -c" after all, not the "synonym" (sic) "od -t -c".

So that's what I'll do.  A bug report against GNU coreutils might also be in order.

G. Branden Robinson <gbranden>
Group administrator
Fri 20 May 2022 04:02:55 AM UTC, comment #12: 

Aha.  macOS is out of conformance with POSIX!  <thunder, rage>


-c
    [XSI] Interpret bytes as characters specified by the current setting of the LC_CTYPE category. Certain non-graphic characters appear as C escapes: "NUL=\0", "BS=\b", "FF=\f", "NL=\n", "CR=\r", "HT=\t"; others appear as 3-digit octal numbers.


https://pubs.opengroup.org/onlinepubs/9699919799/utilities/od.html

"... others appear as 3-digit octal numbers "

But since I don't expect Apple to ever change this--they're Apple--I guess I'll have to go with the "od -b" approach.

(Incidentally, I said in comment #11 that GNU coreutils od output "spaces" for non-printable characters.  That was incorrect, as my own sample output showed.  My eyes had apparently glazed over.)

G. Branden Robinson <gbranden>
Group administrator
Fri 20 May 2022 02:29:20 AM UTC, comment #11: 

comment #10:

> Strange, I'm not seeing a "./build" directory after building.


Naw, that's not strange, I just momentarily forgot that not everyone does out-of-tree builds by default like I do.

The "INSTALL.extra" file documents both forms of building.  It's currently undergoing revision, but as far as I remember nothing about the build location has been inaccurate.

> Instead, each of the executables are merely dumped into the checkout's root directory. Here's the output of `git status --ignored` in case it helps to elucidate which build directories are misconfigured: https://pastebin.com/7rtmxDT6


I scanned over this and nothing looks amiss.  We probably want to add the test-generated .log and .trs files to .gitignore.

>
> > If even that doesn't work, try this.
>
> I ran the command with `./build/{troff,font,grotty}` mapped to `./{troff,font,grotty}` instead (owing to the reasons I described above). Here's the output:
>


> $ printf '" \\[rs] ` - '"'"' ^ ~\n' | ./troff -R -F font -F ./font -Tutf8 | ./grotty -F ./font | od -c
> 0000000                                            "       \       ‘  **
> 0000020   **       ‐  **  **       ’  **  **       ˆ  **       ˜  **  \n
> 0000040   \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n
> *
> 0000140   \n
> 0000141


Aha.  I think we're onto the scent of the beast now.  The correct glyphs are appearing, it's just that the UTF-8 continuation bytes are being represented as double-asterisks instead of spaces!

This is a portability problem.  I'll go see what POSIX says about 'od -c'.  I can either modify the regex in the test script, or change the output format with 'od -b' or similar, and just match the octal representations.

> Alternatively, using xxd(1):


> $ printf '" \\[rs] ` - '"'"' ^ ~\n' | ./troff -R -F font -F ./font -Tutf8 | ./grotty -F ./font | xxd -u -g1
> 00000000: 20 20 20 20 20 20 20 20 20 20 22 20 5C 20 E2 80            " \ ..
> 00000010: 98 20 E2 80 90 20 E2 80 99 20 CB 86 20 CB 9C 0A  . ... ... .. ...
> 00000020: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
> 00000030: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
> 00000040: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
> 00000050: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
> 00000060: 0A


This looks kosher to me.  My output:


$ printf '" \\[rs] ` - '"'"' ^ ~\n' | ./build/troff -R -F font -F build/font -Tutf8 | ./build/grotty -F build/font | xxd -u -g1
00000000: 20 20 20 20 20 20 20 20 20 20 22 20 5C 20 E2 80            " \ ..
00000010: 98 20 E2 80 90 20 E2 80 99 20 CB 86 20 CB 9C 0A  . ... ... .. ...
00000020: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
00000030: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
00000040: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
00000050: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
00000060: 0A                                               .


The problem is a divergence between Linux 'od -c' output and macOS (BSD?) 'od -c' output.  Except I haven't heard any complaints from Ingo, so this may be a true macOS-ism.

Thank you for your help tracking this down.  I think you can disregard this test failure.

I'm still a little worried that your failure changed to a SKIP at one point, though.  Those asterisks should be causing a FAIL against the current design of the test, no question.

We'll see what happens.

G. Branden Robinson <gbranden>
Group administrator
Thu 19 May 2022 05:56:03 PM UTC, comment #10: 

Strange, I'm not seeing a "./build" directory after building. Instead, each of the executables are merely dumped into the checkout's root directory. Here's the output of `git status --ignored` in case it helps to elucidate which build directories are misconfigured: https://pastebin.com/7rtmxDT6

> If even that doesn't work, try this.


I ran the command with `./build/{troff,font,grotty}` mapped to `./{troff,font,grotty}` instead (owing to the reasons I described above). Here's the output:


$ printf '" \\[rs] ` - '"'"' ^ ~\n' | ./troff -R -F font -F ./font -Tutf8 | ./grotty -F ./font | od -c
0000000                                            "       \       ‘  **
0000020   **       ‐  **  **       ’  **  **       ˆ  **       ˜  **  \n
0000040   \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n
*
0000140   \n
0000141


Alternatively, using xxd(1):


$ printf '" \\[rs] ` - '"'"' ^ ~\n' | ./troff -R -F font -F ./font -Tutf8 | ./grotty -F ./font | xxd -u -g1
00000000: 20 20 20 20 20 20 20 20 20 20 22 20 5C 20 E2 80            " \ ..
00000010: 98 20 E2 80 90 20 E2 80 99 20 CB 86 20 CB 9C 0A  . ... ... .. ...
00000020: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
00000030: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
00000040: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
00000050: 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A 0A  ................
00000060: 0A


John Gardner <alhadis>
Thu 19 May 2022 11:06:09 AM UTC, comment #9: 


comment #6:

> comment #5:
> > What does the command "locale charmap" produce on your system?
>
> "UTF-8". Running `locale` without arguments gives:
>


> LANG="en_AU.UTF-8"
> LC_COLLATE="en_AU.UTF-8"
> LC_CTYPE="en_AU.UTF-8"
> LC_MESSAGES="en_AU.UTF-8"
> LC_MONETARY="en_AU.UTF-8"
> LC_NUMERIC="en_AU.UTF-8"
> LC_TIME="en_AU.UTF-8"
> LC_ALL=


This looks completely normal to me.  And that sucks, because it means I have no idea whence this problem arises.

Please try this command from your build.  I'll show you what I get, on my test-passing system.


$ printf '" \\[rs] ` - '"'"' ^ ~\n' | ./build/test-groff -Tutf8 | od -c
0000000   "       \     342 200 230     342 200 220     342 200 231
0000020 313 206     313 234  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n
0000040  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n
*
0000120  \n  \n  \n  \n  \n  \n  \n
0000127


If even that doesn't work, try this.


$ printf '" \\[rs] ` - '"'"' ^ ~\n' | ./build/troff -R -F font -F build/font -Tutf8 | ./build/grotty -F build/font | od -c
0000000                                           "       \     342 200
0000020 230     342 200 220     342 200 231     313 206     313 234  \n
0000040  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n  \n
*
0000140  \n
0000141


G. Branden Robinson <gbranden>
Group administrator
Tue 17 May 2022 02:09:10 AM UTC, comment #8: 

  Should be #62478!

Bjarni Ingi Gislason <bjarniig>
Tue 17 May 2022 02:07:56 AM UTC, comment #7: 

  Look at bug #62474.

Bjarni Ingi Gislason <bjarniig>
Sun 15 May 2022 10:49:53 AM UTC, comment #6: 

comment #5:

> What does the command "locale charmap" produce on your system?


"UTF-8". Running `locale` without arguments gives:


LANG="en_AU.UTF-8"
LC_COLLATE="en_AU.UTF-8"
LC_CTYPE="en_AU.UTF-8"
LC_MESSAGES="en_AU.UTF-8"
LC_MONETARY="en_AU.UTF-8"
LC_NUMERIC="en_AU.UTF-8"
LC_TIME="en_AU.UTF-8"
LC_ALL=


In case it helps, here's the source for macOS's version of locale(1): https://pastebin.com/xV3NwpXR

> You can't.  :-/


Ugh... thanks for confirming what I was starting to fear. Note to self: proofread before posting.

John Gardner <alhadis>
Sun 15 May 2022 09:23:22 AM UTC, comment #5: 

comment #3:

> Sorry for the slow response, I haven't been very good at getting onto the computer [lately].


No worries.  I have likewise been a bit slow to follow-up...
 

> I reran the tests without a LANG environment variable set. Strangely, none of them failed; a few were skipped instead:
>


> # TOTAL: 115
> # PASS:  108
> # SKIP:  2
> # XFAIL: 5
> # FAIL:  0
> # XPASS: 0
> # ERROR: 0


This is pretty good news.

> The complete log is on PasteBin: https://pastebin.com/UUT0DrYP
>
> For the record, my LANG variable was set to `en_AU.UTF-8`. The rest of my environment shouldn't be too problematic, but it's on GitHub should one need it: https://github.com/Alhadis/.files/blob/master/env.sh


It would appear that the command "locale charmap" doesn't work on macOS systems the way it does on Linux.  Here are the commands from the relevant tests that are causing the skips.


$ grep 77 src/roff/groff/tests/smoke-test_html_device.sh
test "$(locale charmap)" = UTF-8 || exit 77 # skip
$ grep -A2 -B8 77 src/devices/grotty/tests/basic_latin_glyphs_map_correctly.sh
        # We can't test UTF-8 if the environment doesn't support it.
        if [ "$(locale charmap)" != UTF-8 ]
        then
            # If we've already seen a failure case, report it.
            if [ -n "$fail" ]
            then
                exit 1 # fail
            else
                exit 77 # skip
            fi
        fi


What does the command "locale charmap" produce on your system?

comment #4:

> > getting onto the computer later.
>
> *lately, not later.
>
> (How does one edit comments on this site?)


You can't.  :-/

Once a comment (or an "original submission") is sent, there's no changing it without administrator assistance.  And I mean Savannah admin, not mere project admins like me.

G. Branden Robinson <gbranden>
Group administrator
Mon 09 May 2022 01:40:46 PM UTC, comment #4: 


> getting onto the computer later.


*lately, not later.

(How does one edit comments on this site?)

John Gardner <alhadis>
Mon 09 May 2022 01:39:30 PM UTC, comment #3: 

Sorry for the slow response, I haven't been very good at getting onto the computer later.

I reran the tests without a LANG environment variable set. Strangely, none of them failed; a few were skipped instead:


# TOTAL: 115
# PASS:  108
# SKIP:  2
# XFAIL: 5
# FAIL:  0
# XPASS: 0
# ERROR: 0


The complete log is on PasteBin: https://pastebin.com/UUT0DrYP

For the record, my LANG variable was set to `en_AU.UTF-8`. The rest of my environment shouldn't be too problematic, but it's on GitHub should one need it: https://github.com/Alhadis/.files/blob/master/env.sh

John Gardner <alhadis>
Sun 08 May 2022 06:16:02 PM UTC, comment #2: 

Hi John,

Ping!

G. Branden Robinson <gbranden>
Group administrator
Mon 25 Apr 2022 04:46:55 PM UTC, comment #1: 

Reproducing my comments from the thread.

> The good news here is that this is only 1 failure, not 6. XFAIL tests are "eXpected to FAIL".  If one one them passes unexpectedly, that's an "XPASS' and might mean a bug was fixed by accident.


> Shooting in the dark here, I'm wondering if the script is failing to detect the unavailability of a UTF-8 character encoding and is running a doomed test.  Bjarni, who often or exclusively uses ISO 8859-15, has more than once exposed robustness oversights in my test scripts in this regard.


Now with my laptop in front of me, I can more comfortably take a look at things.

A number of things could have gone wrong with the check--to avoid trying to match non-basic Latin UTF-8 characters in a shell script, I used printf(1) to send a device-independent output file to grotty, piped its output to od(1), and grep(1)ped the result.  I expended some effort to use these utilities portably, but if I misunderstood POSIX, or if the behavior of the macOS tools or its shell doesn't strictly conform to it, there could well be trouble.

To try and narrow this down, I'm attaching a copy of the troff output file I constructed in a shell variable in the test script.

So to test this, do the following from the Git checkout.


$ ./build/grotty -F ./font -F ./build/font basic_latin.grout | sed '/^$/q'


What glyphs show up on the output?  You can try copy-and-pasting it into a Savannah bug comment and we'll see what shows up.

(file #53148)

G. Branden Robinson <gbranden>
Group administrator
Sun 24 Apr 2022 02:08:08 PM UTC, original submission:  

(Copied from a post submitted to Groff's mailing list this morning)



On macOS, Groff builds and installs perfectly from a fresh checkout (currently using f55d8f41).

However, running `make check` produced 6 failing tests:


FAIL: src/devices/grotty/tests/basic_latin_glyphs_map_correctly.sh
XFAIL: src/roff/groff/tests/string_case_xform_unicode_escape.sh
XFAIL src/roff/groff/tests/string_case_xform_unicode_escape.sh (exit status: 1)
XFAIL: tmac/tests/an-ext_ME-punct-hyphenates.sh
XFAIL tmac/tests/an-ext_ME-punct-hyphenates.sh (exit status: 1)
XFAIL: tmac/tests/an-ext_UE-breaks-before-long-URIs.sh
XFAIL tmac/tests/an-ext_UE-breaks-before-long-URIs.sh (exit status: 1)
XFAIL: tmac/tests/an-ext_UE-punct-hyphenates.sh
XFAIL tmac/tests/an-ext_UE-punct-hyphenates.sh (exit status: 1)
XFAIL: tmac/tests/e_footnotes-work-with-columns.sh
XFAIL tmac/tests/e_footnotes-work-with-columns.sh (exit status: 1)


The first failure bothers me the most, as it relates to something I've noticed Groff doing for a while now:


FAIL: src/devices/grotty/tests/basic_latin_glyphs_map_correctly.sh
==================================================================

checking "ascii" output device...group1 group2 group3 " \ ` ' - ^ ~
checking "latin1" output device...group1 group2 group3 " \ ` ' - ^ ~
checking "utf8" output device...group1 group2 group3 " \ ' FAILED ` FAILED - FAILED ^ FAILED ~ FAILED
FAIL src/devices/grotty/tests/basic_latin_glyphs_map_correctly.sh (exit status: 1)


Attached is a transcript of my shell session and two log files generated by `./configure` and `make check`, respectively.

John Gardner <alhadis>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #53235:  build.log added by alhadis (91KiB - application/octet-stream)
file #53236:  config.log added by alhadis (249KiB - application/octet-stream)
file #53234:  62357-patch.diff added by gbranden (693B - text/x-patch)
file #53148:  basic_latin.grout added by gbranden (570B - application/octet-stream)
file #53141:  build.sh-session added by alhadis (95KiB - application/octet-stream)
file #53142:  config.log added by alhadis (249KiB - application/octet-stream)
file #53143:  test-suite.log added by alhadis (2KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bjarniig (Posted a comment)
  • -email is unavailable- added by gbranden (Updated the item)
  • -email is unavailable- added by alhadis (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-05-21 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
    2022-05-20 alhadis Attached File- Added build.log, #53235
        Attached File- Added config.log, #53236
    2022-05-20 gbranden Attached File- Added 62357-patch.diff, #53234
    2022-05-20 gbranden StatusNeed Info In Progress
    2022-05-15 gbranden Summary[build] Test suite failure on macOS [build] tests using "locale charmap" skipped on macOS
    2022-04-25 gbranden Attached File- Added basic_latin.grout, #53148
        StatusNone Need Info
        Assigned toNone gbranden
    2022-04-24 alhadis Attached File- Added build.sh-session, #53141
        Attached File- Added config.log, #53142
        Attached File- Added test-suite.log, #53143

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code