[Groff] Problems Running a MinGW Built GNU Troff in MSYS RXVT

[MARSHALL Keith]

Hi,

I know Earnie is aware of problems with the RXVT implementation, and is
looking into them among his 'round tuit' items.  I would, however, like
to report an issue noted, while attempting to achieve a stable Win32
implementation of GNU Troff (groff), as I believe it may be worthy of
further attention.

Over the past few days, Werner Lemberg, Jeff Conrad and myself have had
the following discussion, on the groff mailing list, which may be found
at http://ffii.org/archive/mails/groff/, (although some of the dialogue
may have been off-list) -- we had been trying to identify why Win32 builds
of groff, using msvcrt.dll, had been hanging when the postprocessor had
completed the requested page range, (the '-o1' option), and had 
terminated,
while the preprocessor was still trying to write further, unwanted, page
data into the processing pipeline.

>JC:
> Just out of curiosity, when running something like 'groff -eo1' on a 
large
> file on a Unixy system, does eqn respond with 'Broken pipe'?  Does groff
> exit with a non-zero value?
>
>WL:
> Doing `groff -pteo1 -ms pic.ms' on my GNU/Linux box works as expected,
> without any warning or error message.
>
>JC:
> Does it also return zero?  Bruno Haible indicated that a SIGPIPE exit on
> his system exited with 128 + SIGPIPE.
>
>WL:
> Yes. [it does return zero]
>
>KM:
> It also looks fine to me, with a MinGW build from last night's CVS
> snapshot.
>
> But, before we all rush out to celebrate, after doing a 'make install' 
...
>
>    groff -Tps -mom macros.mom
>
> now seems to hang after '%%EOF' is written, and any subsequent 'make', 
which 
> requires this to be rebuilt, will hang at the point where it 
[effectively] 
> executes this, unless I first do a 'make uninstall'.
>
>JC:
> Using a two-day-old snapshot, I don't see this under Win32/MKS/MSVC, 
either
> with or without my changes to run_pipeline().

And, *this* is where I started to focus on MSYS RXVT issues ...

>KM:
> Further investigation suggests that this may be related to a bug in the 
MSYS
> console.  When I execute the above command, it hangs permanently; my 
only
> recourse is to kill the process, and its associated tty, with 'kill -9'.
> However, remembering a tip I wrote in README.MinGW, if I run
>
>    cat | groff -Tps -mom macros.mom
>
> I can recover the prompt by hitting Ctrl-D, to force EOF on STDIN -- but
> *why* is this waiting for STDIN in the first place?

IMO, groff is *not* actually waiting for EOF on STDIN, but RXVT *is*, 
*before*
properly cleaning up the groff process context, and returning to the 
prompt;
effectively it is RXVT that has hung.

>KM:
> It would definitely seem to be a bug associated with the MSYS 
implementation
> of RXVT -- I don't see this problem if I run my MSYS shell in a native 
Windoze
> console, or even if I just run the MinGW built groff under cmd.exe.  It 
also
> works correctly, if I run the MinGW built groff in a Cygwin RXVT.
>
> RXVT looks much prettier, and output to screen is *much* slower in the 
native
> Windoze consoles; shame MSYS RXVT doesn't work more reliably :-(

And it also works correctly running the MinGW built groff in a Cygwin 
shell
in a native Windoze console, or in the konsole window under KDE-Cygwin.

Best regards,
Keith.