From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Eli Zaretskii" To: cygwin@cygwin.com, gdb@sources.redhat.com Cc: Takaaki.Ota@am.sony.com, cygwin@cygwin.com, gdb@sources.redhat.com, jimb@redhat.com Subject: Re: gdb run < file Date: Fri, 29 Jun 2001 00:20:00 -0000 Message-id: <2427-Fri29Jun2001101154+0300-eliz@is.elta.co.il> References: <20010626.234402.21347360.Takaaki.Ota@am.sony.com> <20010627025036.B20160@redhat.com> <20010627.235700.01365880.Takaaki.Ota@am.sony.com> <20010628220602.A3596@redhat.com> X-SW-Source: 2001-06/msg00231.html > Date: Thu, 28 Jun 2001 22:06:02 -0400 > From: Christopher Faylor > > I'm sorry but I don't think that this is the correct way to deal with > this. I think that gdb normally handles things like redirection and > globbing by starting inferior processes via the user's shell. Then it > uses some kind of "follow fork" method to notice when the process is > finally started. I don't know anything about Windows debugging interface, but it might be that putting a shell between the debugger and the debuggee breaks something. Going through the shell also has the limitation that you buy whatever idiosyncrasies there are in that shell. Unlike on Unix, where the redirection behavior is quite similar between the shells, on Windows there's a very wide disagreement. (We are fed up with that nuisance in the Emacs-land.) So I think there's a lot of sense in having a unified, predictable redirection support inside GDB that doesn't depend on the queer shell the user happens to have. FWIW, the DJGPP port of GDB does something very similar to the patch we discuss here (except that it also has to flip redirections every time the execution thread jumps from the debugger to the debuggee). See go32-nat.c (the actual implementation of the redirection routines is in the DJGPP debug support library).