Re: [Mingw-users] Interactive mode in MSYS shell

[James S. <jam...@op...>]

On Thu, 2007-03-29 at 11:30 +0100, Keith MARSHALL wrote:
> RXVT owns the `stdin', `stdout' and `stderr' file descriptors bound to
> your console, and uses pipes to connect these to your shell, and to any
> process you invoke from that shell.  A pipe is not a tty, so `isatty()'
> returns `false', for these `stdio' streams in the application; thus,
> the standard runtime init routines enable block buffering for these
> streams, rather than the expected line buffered or unbuffered modes.
> This causes at least two serious problems for interactive console
> applications, run within an RXVT:
> 
> 1) Expected output is delayed in the block buffer, instead of
>    appearing on the screen; users are left waiting for prompts
>    that never appear on the screen, yet the application has
>    moved on, and is waiting for their input, (unless the
>    application has been sprinkled with `flush()' calls, to
>    explicitly work around this abnormal behaviour).

I've noticed this undesirable behaviour.  Even sprinkles of flush don't
always seem to do enough for me at times.  I guess I've worked around
the behaviour in what I've tinkered with so far on XP.

> 2) Special characters, such as ^D or ^Z, which users expect to
>    be able to use to signal EOF on input are swallowed by RXVT;
>    applications which loop until EOF on `stdin' are locked into
>    a perpetual interminable state.

I'd not noticed this one.  (Or maybe I discounted it as a silly windows
glitch ;-) Eek.

> The above is a consequence of Win32's lack of *nix's `pty' feature;
> trying to emulate it with pipes just isn't at all satisfactory.  I do
> know that Earnie has put considerable effort into seeking a solution
> to this `pty' emulation problem, with frustrating lack of success.

Bother.  So we need some pty replacement scheme?  Could something be
employed along the lines of the OutputDebugString mechanism?  As far as
I understand it, it uses a 4k block of shared memory?  And some mutex or
other objects to synchronise message passing through the block.  Could
this idea be elaborated on to provide some sort of pty like behaviour? 

> > Having a Linux background I would prefer a console that appears most
> > like a KDE Console or Gnome terminal for example.
> 
> You and I both.  The online screenshots for the console-2 application
> Brian mentioned appear temptingly close to offering something close to
> a KDE Konsole-like experience; sadly, and frustratingly for me, the
> reality fell far short of expectation.

Darn.

> > Why was Earnie keen to promote RXVT?
> 
> I really couldn't say.  When asked, his strongest argument seemed to be
> the xterm style copy and paste feature, but with appropriate configuration
> the native console offers a similar capability.  RXVT seems to offer two
> advantages over native console:
> 
> 1) It can be resized `on-the-fly', simply by dragging the window
>    frame; native console can also be resized, but only by changing
>    row/column settings in the GUI configuration dialogue.
> 
> 2) RXVT uses ^D for EOF, (but doesn't forward it reliably to running
>    applications), and ^Z offers some limited interactive job control
>    features, as in *nix; native console doesn't treat ^D specially,
>    uses ^Z for EOF, and lacks any form of interactive job control.
> 
> For me, neither of these offers a sufficiently strong advantage to 
> mitigate
> the attendant problems; others may hold a contrary view, and must decide
> their own individual preferences.

Thanks a lot for the detailed explanation and comparison Keith.

Cheers,
James.