[Top][All Lists]

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

Re: asynchronous process management on WinWP; buffering problem?

From: Lennart Borgman
Subject: Re: asynchronous process management on WinWP; buffering problem?
Date: Sun, 16 Apr 2006 01:50:09 +0200
User-agent: Thunderbird 1.5 (Windows/20051201)

Hi Benny,

Thanks for the good explanation. Indeed it looks difficult to fix this on the w32 platform. In my opinion w32 does not look very much POSIX conformant here. Or the POSIX specs are just too weak.

Benjamin Riefenstahl wrote:
The function isatty is defined in the Microsoft C runtime, and that is
what Mingw uses.  This version of isatty determines if a program is
running with stdin/stdout connected to an MS Windows console.

The way that consoles are implemented and used in MS Windows makes it
very complicated to use the console API to simulate a terminal in
Emacs.  On Unix-like systems this is done by so-called "pseudo-ttys",
"pty", but the MS Windows consoles are quite different beasts at the
OS API level.  Emacs would have to do a large amount of
reverse-engineering of the intent of the child process, to do with
consoles what Emacs does quite naturally on Unix with pseudo-ttys, and
there would still be features missing.  Therefore Emacs just uses
anonymous pipes instead which are a much better fit for the way Emacs
treats child processes, but that means that it can't make isatty in
child processes return true.

Cygwin can implement pseudo-ttys if it controls the parent as well as
the child, e.g. when you call a Cygwin program from a Cygwin compiled
Emacs.  It uses its own conventions to do that which are not
understood by non-Cygwin programs.

Sometimes you have a program that uses isatty to determine if it
should work in interactive mode or not, like the command shells of a
programming language or the some SQL interpreters.  In those cases you
will need to find a way put it into interactive mode without the help
of isatty.  Sometimes the shell will have a command-line option for
that, in other cases it can be configured after its start.


reply via email to

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