[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Ingo Schwarze
Subject: Re: [groff] 1.22.4.rc4 - Final RC before official 1.22.4
Date: Fri, 7 Dec 2018 15:18:41 +0100
User-agent: Mutt/1.8.0 (2017-02-23)

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

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

 $ make
make  all-am
  GROFF    contrib/hdtbl/examples/
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/

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

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]