Re: [Groff] .rd request

[Ralph Corderoy]

Hi,

I wrote:
> But this appears to be a bug in groff with the introduction of
> preconv.  Consider
> 
>     $ printf 'foo\n\n' |
>     > preconv |
>     > strace -fe trace=read nroff <(printf 'a\n.rd\nb\n') 2> >(grep 
> 'read(0,') |
>     > grep .
>     a b
>     [pid  4344] read(0,  <unfinished ...>
>     [pid  4343] read(0, ".lf 1 /dev/fd/63\na\n.rd\nb\n", 4096) = 25
>     [pid  4343] read(0, "", 4096)           = 0
>     [pid  4343] read(0, "", 4096)           = 0
>     $ 
> 
> I think the original file descriptor 0 is closed, the pipe from
> preconv is dup(2)'d onto it, the preconv'd output of groff's input is
> read, EOF is reached, and then the later processing of .rd correctly
> attempts to read from FD 0 only to again see EOF.

I'm wrong.  It's not preconv's fault.

    $ printf 'foo\n\n' | groff -Tascii <(printf 'a\n.rd\nb\n') | grep .
    a foo b
    $ printf 'foo\n\n' | groff -Tascii -t <(printf 'a\n.rd\nb\n') | grep .
    a b
    $ 

Anything that means troff isn't first in the pipeline causes groff's
pipeline.c to trample troff's FD 0.

    $ groff -V -Tascii <(printf 'a\n.rd\nb\n')
    troff -Tascii /dev/fd/63 | grotty
    $ groff -V -Tascii -t <(printf 'a\n.rd\nb\n')
    tbl /dev/fd/63 | troff -Tascii | grotty
    $ 

(nroff(1) is just a shell script that runs groff(1) so GROFF_ENCODING is
still examined, causing preconv to be inserted.  That's why my tests
were also falling foul.)

It seems [gn]roff's pipelining building can be incompatible with .rd.
Should this be noted somewhere, including outside of TeXinfo.

Cheers,
Ralph.