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.
