This is the mail archive of the
cygwin@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: bash-shell output
- To: fjh at cs dot mu dot OZ dot AU
- Subject: Re: bash-shell output
- From: Andrew Innes <andrewi at harlequin dot co dot uk>
- Date: Thu, 5 Feb 1998 12:13:20 GMT
- CC: ngo at wossolit dot teles dot de, gnu-win32 at cygnus dot com
On Thu, 5 Feb 1998 14:20:20 +1100, Fergus Henderson <fjh@cs.mu.OZ.AU> said:
>On 04-Feb-1998, Andrew Innes <andrewi@harlequin.co.uk> wrote:
>>On 04 Feb 1998 17:07:50 -0800, Nils Goesche <ngo@wossolit.teles.de> said:
>>>You have to uncomment that fflush-line. But the usual shells
>>>like command.com or 4nt don't need that line. This is somewhat
>>>annoying. Can I at least force the shell somehow to flush
>>>input/output buffers? Some other programs are just unusable
>>>because of this behavior.
>>
>>This is a consequence of the design of Windows (well, that combined with
>>the behaviour of the Microsoft C runtime library).
>>
>>Most DOS/Windows compilers make stdout unbuffered if isatty() returns
>>true, and isatty() in turn calls GetFileType on the OS file handle - if
>>the handle is a console handle, then isatty returns true.
>>
>>Emacs has to redirect stdin and stdout/stderr for subprocesses through
>>pipes so it can communicate with them, but cannot hide the fact that
>>the handles are pipe handles.
>
>Does that mean that
> - a proper pseudo-tty implementation (one for which isatty() would
> return true) is not possible on Windows?
> - a proper pseudo-tty implementation is possible, but cygwin32
> doesn't have one yet?
> - a proper pseudo-tty implementation is possible, and cygwin32
> has one, but emacs doesn't use it?
Either (2) or (3).
Technically, it is possible to implement (something like) ptty's in such
a way that they will work without applications being aware of them
(except the host application that creates the ptty, I mean).
The mechanism I am thinking of for doing this is rather hacky though; it
involves a mixture of the techniques described by Matt Pietrek and
Jeffrey Richter for "injecting" dlls and intercepting system api calls.
I've got some experimental code I wrote a few years ago for Emacs which
puts some of the pieces in place (specifically I implemented a variation
on the method for injecting a dll when creating a process which doesn't
require debugging the child process). I'm hoping to eventually turn
this into a self-injecting dll which can be used to implement facilities
like pttys that aren't directly provided by the Windows api.
AndrewI
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".