Re: [mingw32] stdin redirection

[Joel Brobecker <brobecker at adacore dot com>]

> So fd_is_pipe returns zero either way, but something about calling
> PeekNamedPipe on a non-pipe disturbs what happens later, you're saying.

Yes, it appears so.

> How did it get into WaitForMultipleObjects?  Did isatty return true -
> in which case it shouldn't have called fd_is_pipe?

One piece of information that might be important is the fact that
we are running from a cygwin shell. In this case, we no longer have
ttys regardless of the way we start GDB (in "terminal" mode, or in
non-interactive mode). However, we tried in a DOS window as well,
and we had the same result: isatty return false, thus leading us
to call fd_is_pipe, followed by the hang up.


> Otherwise, see the call site, where no handle is provided.
> So we must be falling back to the file handle (mingw-hdep.c).
> Maybe we need to do something different to simulate select on a file.

Sorry, we're not sure what you mean. Could you elaborate?

We've done a bit of debugging on our side, and we now have a better
idea of the serial interface in GDB, and probably of why the select
layer is implemented the way it is implemented in ser-mingw and
mingw-hdep.c. It seems to us that the core of the problem in this
case is that PeekNamedPipe does indeed seem to corrupt whatever
control structure is associated to our HANDLE.

If we could find a way to replace the current implementation of
fd_is_pipe into something that avoids using any of the pipe functions,
then that would probably solve our problem. Unfortunately, despite
our intensive search of MSDN, nothing turned up.

However, the little hack we have been using in fd_is_pipe (basically
always return false) seems to indicate that it is OK to treat the
case of pipes and files the same way. We currently have the following
code:

      is_tty = isatty (scb->fd);
      if (!is_tty && !fd_is_pipe (scb->fd))
        {
          *read = NULL;
          *except = NULL;
          return;
        }
      [otherwise, create a bunch of event objects]

All the conditions we have tried (interactive-mode in DOS window,
interactive mode DOS window but called from cygwin shell, interactive
mode from XTERM with cygwin shell, commands sent through pipe in
cygwin shell, commands though pipe in DOS window, commands through
file in both DOS window and XTERM with cygwin, etc...).

So I wonder if it wouldn't just be sufficient to replace the body
of fd_is_pipe by a big comment, followed by "return !isatty (fd);".
Or, since this function only used there, replace the if condition
by
  
      if (!is_tty))

Which basically means that we limit the "else" block to the handling
of the case when we have a tty. We haven't found any problem with
that approach in all the experiments that we have done. Is there
something we haven't seen, though?

Thanks,
-- 
Joel