Re: [groff] 1.22.4.rc4 - Final RC before official 1.22.4

[Ingo Schwarze]

Hi Ralph,

Ralph Corderoy wrote on Fri, Dec 07, 2018 at 11:06:53AM +0000:

> I wasn't going to bother Ingo, given all the ports-testing he's doing,
> but since popped up...
> 
> The time-honoured way to get modern-day `printf foo' is
> 
>     echo foo | tr -d \\012
> 
> If groff's still hoping to build on those old systems then that's how to
> do it.

Thanks for looking at it, but unfortunately, that does not work at all.
I just tested the version you suggest, and even on OpenBSD, it does not
work:

.  pso sh -c \
       "printf '%s' '.ds *f ' ; \
        ls \\*[fontpath]/dev\*[.T] \
        | tr -d \\012"

 $ make
make  all-am
  GROFF    contrib/hdtbl/examples/fonts_n.ps
fonts_n.roff: listing fonts in ../font/devps
fonts_n.roff: listing font 'AB'...

Note that only one font is processed.

========================================
   GNU Troff 1.22.4: ./test-suite.log
========================================

# TOTAL: 3
# PASS:  2
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: contrib/hdtbl/examples/test-hdtbl.sh
==========================================

Checking /co/groff/build/contrib/hdtbl/examples/fonts_n.ps
  Error: expected 38 pages, found        1 pages
Checking /co/groff/build/contrib/hdtbl/examples/fonts_x.ps


I think there are three problems with the version you propose:

 1. Insufficient escaping.
    The first conversion of "\\" to "\" is done when groff defines
    the macro,  The second interpretation of backslashes is done
    when groff executes the macro; "\0" is an "unpaddable, breaking
    digit-width space".  So the escape sequence never arrives at the
    shell.  I didn't easily figure out the right amount of escaping.
    It is hard to debug because you never get to see what the shell
    actually runs, nor the output from it.

 2. Even if that could be done, -d is wrong here, the newlines
    must be translated to blanks, not deleted, or all the font
    filenames will be concatenated into one single word.

 3. I'm not convinced what you propose, even after fixing the above
    two issues, will work under exotic locales like EBCDIC or UTF-32,
    and i cannot test under any exotic locales.

Can you propose a specific patch for your idea that actually works?

Thanks,
  Ingo