From: Earnie B. <ea...@us...> - 2005-04-17 06:32:26
|
Msys developers, I'm wondering how we're doing tracking down this bug. I would like for discussion on this list so please feel free to respond here. What we know is that the stdout is blocked until the pipe is full in the child process. What we don't know is how to change that mode for the child process. This is relative to RXVT using pty, which it rightly should, but tty pipes work without a hitch. Earnie |
From: Julien L. <jul...@fr...> - 2005-04-17 11:46:02
|
Hello Earnie & Team, I've started writing tutorials on MinGW / mSys. They are available on my website : www.amanitamuscaria.org. You are free of course to copy them to the MinGW wiki. I haven't set them myself on the wiki as there is some website errors when trying to set up a new account. Concerning the RXVT bug (output is not sent to RXVT) : - If you rename/remove the /bin/ftp file then output is sent to RXVT. In this case, the file /bin/ftp.exe is executed. I haven't be able to drack down where /bin/ftp.exe comes from (since it does depend on the msys dll) - If you change /bin/ftp to `cmd //c ftp "$@"` (or simply remove /bin/ftp.exe and /bin/ftp file) then output is also sent back to RXVT / Dos box. In the case of the Dos box, we receive all stdin/out/err. In the case of RXVT, we receive stderr and stdout but not the notification messages (ie: "220 GNU FTP server ready."). In other words, I don't believe that starting a 'native' dos program (such as ftp) should be called by using `cmd //c start ...`; this avoids a new window being opened. As for the output of notification messages, I haven't a single clue why they aren't stdout or stderr ! For the time being, I'm currently lost on this one. Julien -----Original Message----- From: min...@li... [mailto:min...@li...] On Behalf Of Earnie Boyd Sent: dimanche 17 avril 2005 08:37 To: min...@li... Subject: [MinGW-dvlpr] [MSYS] RXVT bug Msys developers, I'm wondering how we're doing tracking down this bug. I would like for discussion on this list so please feel free to respond here. What we know is that the stdout is blocked until the pipe is full in the child process. What we don't know is how to change that mode for the child process. This is relative to RXVT using pty, which it rightly should, but tty pipes work without a hitch. Earnie ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ MinGW-dvlpr mailing list Min...@li... https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Earnie B. <ea...@us...> - 2005-04-17 12:25:19
|
On 11:45:50 am 2005-04-17 "Julien Lecomte" <jul...@fr...> wrote: > > Hello Earnie & Team, > > I've started writing tutorials on MinGW / mSys. They are available on > my website : www.amanitamuscaria.org. You are free of course to copy > them to the MinGW wiki. I haven't set them myself on the wiki as > there is some website errors when trying to set up a new account. > And silence about that trouble is likely to not get anything fixed. Are you saying that a user id of JulienLecomte doesn't allow you to edit pages? You followed the instructions of http://www.mingw.org/MinGWiki/index.php/MinGWiki%20Pages, correct? > Concerning the RXVT bug (output is not sent to RXVT) : > - If you rename/remove the /bin/ftp file then output is sent to RXVT. > In this case, the file /bin/ftp.exe is executed. I haven't be able to > drack down where /bin/ftp.exe comes from (since it does depend on the > msys dll) - /bin/ftp is an msys dependent program, of course that works. As was stated in the action item, to exercise the bug simply use ``start rxvt -e $SYSTEMROOT/system32/ftp'' and type help in the window that is started. > If you change /bin/ftp to `cmd //c ftp "$@"` (or simply > remove /bin/ftp.exe and /bin/ftp file) then output is also sent back > to RXVT / Dos box. In the case of the Dos box, we receive all > stdin/out/err. In the case of RXVT, we receive stderr and stdout but > not the notification messages (ie: "220 GNU FTP server ready."). > > In other words, I don't believe that starting a 'native' dos program > (such as ftp) should be called by using `cmd //c start ...`; this > avoids a new window being opened. > As for the output of notification messages, I haven't a single clue > why they aren't stdout or stderr ! > It has nothing really to do with ftp. You can create a simple program that accepts data from stdin and writes it back out to stdout. It is the internals of MSYS and not the externals that is the problem. > For the time being, I'm currently lost on this one. > A bit obvious. Hopefully we can get the MSYS developers educated to understand the problem enough to fix it. Earnie > Julien > > > > > -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf Of Earnie > Boyd Sent: dimanche 17 avril 2005 08:37 > To: min...@li... > Subject: [MinGW-dvlpr] [MSYS] RXVT bug > > Msys developers, > > I'm wondering how we're doing tracking down this bug. I would like > for discussion on this list so please feel free to respond here. > What we know is that the stdout is blocked until the pipe is full in > the child process. What we don't know is how to change that mode for > the child process. This is relative to RXVT using pty, which it > rightly should, but tty pipes work without a hitch. > > Earnie > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide Read honest & candid > reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real > users. Discover which products truly live up to the hype. Start > reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Martin R. <sfp...@gm...> - 2005-06-23 19:20:34
|
Don't know if this is already known, flushing stdout makes the problem go away. This is not a solution, but maybe somebody understands the=20 semantics of flushing ptys and why it makes things different. while ( ( c =3D getchar() ) !=3D -1 && c !=3D 'q' ) { =20 putchar(c); // doesn't work } while ( ( c =3D getchar() ) !=3D -1 && c !=3D 'q' ) { =20 putchar(c); // works fflush(stdout); } Martin On 4/17/05, Earnie Boyd <ea...@us...> wrote: >=20 > It has nothing really to do with ftp. You can create a simple program th= at > accepts data from stdin and writes it back out to stdout. It is the > internals of MSYS and not the externals that is the problem. >=20 > > For the time being, I'm currently lost on this one. > > >=20 > A bit obvious. Hopefully we can get the MSYS developers educated to > understand the problem enough to fix it. >=20 > Earnie >=20 > > Julien > > > > > > > > > > -----Original Message----- > > From: min...@li... > > [mailto:min...@li...] On Behalf Of Earnie > > Boyd Sent: dimanche 17 avril 2005 08:37 > > To: min...@li... > > Subject: [MinGW-dvlpr] [MSYS] RXVT bug > > > > Msys developers, > > > > I'm wondering how we're doing tracking down this bug. I would like > > for discussion on this list so please feel free to respond here. > > What we know is that the stdout is blocked until the pipe is full in > > the child process. What we don't know is how to change that mode for > > the child process. This is relative to RXVT using pty, which it > > rightly should, but tty pipes work without a hitch. > > > > Earnie > > |
From: Earnie B. <ea...@us...> - 2005-06-23 22:53:42
|
On 7:20:18 pm 2005-06-23 Martin Redmond <sfp...@gm...> wrote: > Don't know if this is already known, flushing stdout makes the problem > go away. This is not a solution, but maybe somebody understands the > semantics of flushing ptys and why it makes things different. > > while ( ( c = getchar() ) != -1 && c != 'q' ) { > putchar(c); // doesn't > work } > > while ( ( c = getchar() ) != -1 && c != 'q' ) { > putchar(c); // works > fflush(stdout); > } > Yes it is known. The reason is that the flush exposes data to the underlying pipe. The problem only exists on stdout and not on stdin or stderr. I've not found a method to force the native executable to do the right thing w.r.t. MSYS spawning the native process. Earnie > > Martin > > On 4/17/05, Earnie Boyd <ea...@us...> wrote: > > > > > It has nothing really to do with ftp. You can create a simple > > program that accepts data from stdin and writes it back out to > > stdout. It is the internals of MSYS and not the externals that is > > the problem. > > > For the time being, I'm currently lost on this one. > > > > > > > A bit obvious. Hopefully we can get the MSYS developers educated > > to understand the problem enough to fix it. > > > > Earnie > > > > > Julien > > > > > > > > > > > > > > > -----Original Message----- > > > From: min...@li... > > > [mailto:min...@li...] On Behalf Of > > > Earnie Boyd Sent: dimanche 17 avril 2005 08:37 > > > To: min...@li... > > > Subject: [MinGW-dvlpr] [MSYS] RXVT bug > > > > > > Msys developers, > > > > > > I'm wondering how we're doing tracking down this bug. I would > > > like for discussion on this list so please feel free to respond > > > here. What we know is that the stdout is blocked until the pipe > > > is full in the child process. What we don't know is how to > > > change that mode for the child process. This is relative to > > > RXVT using pty, which it rightly should, but tty pipes work > > > without a hitch. > > > Earnie > > > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&opick > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Christopher F. <me...@cg...> - 2005-06-24 23:10:25
|
On Thu, Jun 23, 2005 at 10:54:34PM +0000, Earnie Boyd wrote: >On 7:20:18 pm 2005-06-23 Martin Redmond <sfp...@gm...> wrote: >>Don't know if this is already known, flushing stdout makes the problem >>go away. This is not a solution, but maybe somebody understands the >>semantics of flushing ptys and why it makes things different. >> >>while ( ( c = getchar() ) != -1 && c != 'q' ) { >> putchar(c); // doesn't >>work } >> >>while ( ( c = getchar() ) != -1 && c != 'q' ) { >> putchar(c); // works >> fflush(stdout); >> } >> >Yes it is known. The reason is that the flush exposes data to the >underlying pipe. The problem only exists on stdout and not on stdin or >stderr. I've not found a method to force the native executable to do >the right thing w.r.t. MSYS spawning the native process. FWIW, this has always been a problem with Cygwin, too. It's hard to see how this could be fixed without reinventing ptys. If there was some way to have an invisible console which took input and output for a pty that might do it, I guess... cgf |
From: Earnie B. <ea...@us...> - 2005-06-25 00:08:56
|
On 11:10:12 pm 2005-06-24 Christopher Faylor <me...@cg...> wrote: > On Thu, Jun 23, 2005 at 10:54:34PM +0000, Earnie Boyd wrote: > > On 7:20:18 pm 2005-06-23 Martin Redmond <sfp...@gm...> > >> wrote: Don't know if this is already known, flushing stdout makes > >> the problem go away. This is not a solution, but maybe somebody > >> understands the semantics of flushing ptys and why it makes things > >> different. > >> while ( ( c = getchar() ) != -1 && c != 'q' ) { > >> putchar(c); // doesn't > >> work } > >> > >> while ( ( c = getchar() ) != -1 && c != 'q' ) { > >> putchar(c); // works > >> fflush(stdout); > >> } > >> > > Yes it is known. The reason is that the flush exposes data to the > > underlying pipe. The problem only exists on stdout and not on > > stdin or stderr. I've not found a method to force the native > > executable to do the right thing w.r.t. MSYS spawning the native > process. > > FWIW, this has always been a problem with Cygwin, too. It's hard to > see how this could be fixed without reinventing ptys. If there was > some way to have an invisible console which took input and output > for a pty that might do it, I guess... > It may be possible with the new console functions. It would limit the fix to XP and greater though. Earnie |
From: Christopher F. <me...@cg...> - 2005-06-25 03:22:08
|
On Sat, Jun 25, 2005 at 12:09:48AM +0000, Earnie Boyd wrote: >On 11:10:12 pm 2005-06-24 Christopher Faylor <me...@cg...> wrote: >> On Thu, Jun 23, 2005 at 10:54:34PM +0000, Earnie Boyd wrote: >> > On 7:20:18 pm 2005-06-23 Martin Redmond <sfp...@gm...> >> >> wrote: Don't know if this is already known, flushing stdout makes >> >> the problem go away. This is not a solution, but maybe somebody >> >> understands the semantics of flushing ptys and why it makes things >> >> different. >> >> while ( ( c = getchar() ) != -1 && c != 'q' ) { >> >> putchar(c); // doesn't >> >> work } >> >> >> >> while ( ( c = getchar() ) != -1 && c != 'q' ) { >> >> putchar(c); // works >> >> fflush(stdout); >> >> } >> >> >> > Yes it is known. The reason is that the flush exposes data to the >> > underlying pipe. The problem only exists on stdout and not on >> > stdin or stderr. I've not found a method to force the native >> > executable to do the right thing w.r.t. MSYS spawning the native >> process. >> >> FWIW, this has always been a problem with Cygwin, too. It's hard to >> see how this could be fixed without reinventing ptys. If there was >> some way to have an invisible console which took input and output >> for a pty that might do it, I guess... > >It may be possible with the new console functions. It would limit the fix >to XP and greater though. Aye, there's the rub. cgf |
From: Max T. W. <ma...@mt...> - 2005-06-25 04:27:07
|
Christopher Faylor wrote: > > On Sat, Jun 25, 2005 at 12:09:48AM +0000, Earnie Boyd wrote: > >On 11:10:12 pm 2005-06-24 Christopher Faylor <me...@cg...> wrote: > >> On Thu, Jun 23, 2005 at 10:54:34PM +0000, Earnie Boyd wrote: > >> > On 7:20:18 pm 2005-06-23 Martin Redmond <sfp...@gm...> > >> >> wrote: Don't know if this is already known, flushing stdout makes > >> >> the problem go away. This is not a solution, but maybe somebody > >> >> understands the semantics of flushing ptys and why it makes things > >> >> different. > >> >> while ( ( c = getchar() ) != -1 && c != 'q' ) { > >> >> putchar(c); // doesn't > >> >> work } > >> >> > >> >> while ( ( c = getchar() ) != -1 && c != 'q' ) { > >> >> putchar(c); // works > >> >> fflush(stdout); > >> >> } > >> >> > >> > Yes it is known. The reason is that the flush exposes data to the > >> > underlying pipe. The problem only exists on stdout and not on > >> > stdin or stderr. I've not found a method to force the native > >> > executable to do the right thing w.r.t. MSYS spawning the native > >> process. > >> > >> FWIW, this has always been a problem with Cygwin, too. It's hard to > >> see how this could be fixed without reinventing ptys. If there was > >> some way to have an invisible console which took input and output > >> for a pty that might do it, I guess... > > > >It may be possible with the new console functions. It would limit the fix > >to XP and greater though. > > Aye, there's the rub. > > cgf IIRC stdout may or may not be put into 'line' mode depending on what kind of device it is connected to. It is not usually in 'line' mode if it is connected to a file, but is usually in that mode if it is connected to a display device. In 'line' mode, it's supposed to get flushed automatically at the end of each line or more frequently depending on the implementation. OTOH stderr is almost always put into 'line' mode, even when connected to a file. That implies a way to check the kind of device being connected to. I believe that check is done by 'istty'. That means a 'ptty' should cause 'istty' to return true. Does it? Also, if that isn't enough, an extra flush could be called somewhere in the library code if 'istty' is true and you're about to return to the user... Max |
From: Earnie B. <ea...@us...> - 2005-06-25 15:12:53
|
On 4:26:31 am 2005-06-25 "Max T. Woodbury" <ma...@mt...> wrote: > Christopher Faylor wrote: > > > > On Sat, Jun 25, 2005 at 12:09:48AM +0000, Earnie Boyd wrote: > > > On 11:10:12 pm 2005-06-24 Christopher Faylor <me...@cg...> wrote: > > >> On Thu, Jun 23, 2005 at 10:54:34PM +0000, Earnie Boyd wrote: > > >> > On 7:20:18 pm 2005-06-23 Martin Redmond <sfp...@gm... > m> > > >> >> wrote: Don't know if this is already known, flushing stdout > > >> >> makes the problem go away. This is not a solution, but > > >> >> maybe somebody understands the semantics of flushing ptys > > >> >> and why it makes things different. > > >> >> while ( ( c = getchar() ) != -1 && c != 'q' ) { > > >> >> putchar(c); // > > >> >> doesn't work } > > >> >> > > >> >> while ( ( c = getchar() ) != -1 && c != 'q' ) { > > >> >> putchar(c); // > > >> >> works fflush(stdout); > > >> >> } > > >> >> > > >> > Yes it is known. The reason is that the flush exposes data > > >> > to the underlying pipe. The problem only exists on stdout > > >> > and not on stdin or stderr. I've not found a method to force > > >> > the native executable to do the right thing w.r.t. MSYS > > >> spawning the native process. > > >> > > >> FWIW, this has always been a problem with Cygwin, too. It's > > >> hard to see how this could be fixed without reinventing ptys. > > >> If there was some way to have an invisible console which took > > >> input and output for a pty that might do it, I guess... > > > > > > It may be possible with the new console functions. It would > > > limit the fix to XP and greater though. > > > > Aye, there's the rub. > > > > cgf > > IIRC stdout may or may not be put into 'line' mode depending on what > kind of device it is connected to. It is not usually in 'line' mode > if it is connected to a file, but is usually in that mode if it is > connected to a display device. In 'line' mode, it's supposed to get > flushed automatically at the end of each line or more frequently > depending on the implementation. OTOH stderr is almost always put > into 'line' mode, even when connected to a file. > > That implies a way to check the kind of device being connected to. > I believe that check is done by 'istty'. That means a 'ptty' should > cause 'istty' to return true. Does it? > Yes and no. It does for an msys dll dependent app. It does not for a native app. PTY is implemented using pipes. > Also, if that isn't enough, an extra flush could be called somewhere > in the library code if 'istty' is true and you're about to return to > the user... > If you don't have the source, it is much difficult to do that. The native app I've suggested to try is the MS supplied ftp. To see the effects of the unending feature try ``rxvt -e $SYSTEMROOT/system32/ftp''. I have not found a way to set the stdout in line mode on the child process. If that were able to be accomplished then perhaps the issue could be fixed. Earnie |
From: Christopher F. <me...@cg...> - 2005-06-25 22:06:11
|
On Sat, Jun 25, 2005 at 03:13:46PM +0000, Earnie Boyd wrote: >I have not found a way to set the stdout in line mode on the child >process. If that were able to be accomplished then perhaps the issue >could be fixed. I wonder if there's some way to tell msvcrt that an inherited handle is autoflush. google doesn't seem to imply that there is, though. cgf |
From: Earnie B. <ea...@us...> - 2005-06-25 22:22:28
|
On 10:05:36 pm 2005-06-25 Christopher Faylor <me...@cg...> wrote: > On Sat, Jun 25, 2005 at 03:13:46PM +0000, Earnie Boyd wrote: > > I have not found a way to set the stdout in line mode on the child > > process. If that were able to be accomplished then perhaps the > > issue could be fixed. > > I wonder if there's some way to tell msvcrt that an inherited handle > is autoflush. google doesn't seem to imply that there is, though. > What intriques me is that without the rxvt pty the stdout is not an issue. Earnie |