Hi Takashi, On Apr 13 19:31, Takashi Yano wrote: > Hi Corinna, > > I'm sorry for late reply.
No worries. > On Tue, 7 Apr 2015 11:11:13 +0200 > Corinna Vinschen <corinna-cyg...@cygwin.com> wrote: > > > I think we should move opost processing back to the master side. Would > > it be much of a problem to restructure your patch to do that, without > > re-introducing the old problems your patch fixed? > > I am considering of this issue for several days. > However, it is still with dificulty. > > For my better understanding, may I ask a question? > > At where does cygwin set the standard output handle > for native windows programs to fhandler_pty_slave:: > output_handle? It doesn't. The only way to set a handle for a native client is by propagating the handle via execve. And the native client, not knowing what he's talking to, recognizes the output stream as a normal named pipe, if it's looking for that info at all. Being native, it will use native Windows MSVCRT stdio calls. Worse, as you can see in the behaviour of some native applications, the MSVCRT isatty() call returns 0 for named pipes. If we have a Cygwin client, we can do all kinds of stuff on the slave side, but as soon as we have a native client, only the master side of the pty has any chance to do the right thing. That's why I wrote that we don't have the slave side under control. Therefore we should really move the OPOST code back to the master side. I'm reluctant to just revert your patch, though, because I think you know better how to fix the OPOST code to make it work correctly on the master side. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgpHRcTSMF0lz.pgp
Description: PGP signature
