From mboxrd@z Thu Jan 1 00:00:00 1970 From: Earnie Boyd To: cygwin users Subject: RE: cat broken Date: Thu, 24 Jun 1999 10:56:00 -0000 Message-id: <19990624175704.27192.rocketmail@web126.yahoomail.com> X-SW-Source: 1999-06/msg00583.html --- John Wiersba wrote: > Phil: OK, I see what you're saying now. > > What I was talking about was a duplicate echo. Not the normal echoing of > characters which you can turn on and off with stty, but a *second* copy of > the line you just typed which is echoed immediately after pressing the ENTER > key. > > cat > file > this is a test. (ENTER pressed here) > this is a test. > please stop repeating what I say (ENTER pressed here) > please stop repeating what I say > ... > > cat is broken in the 5/23 release, fixed in the 1/16 and 6/10 releases (I > don't know why). > Let's restate this: It isn't cat that is broken but the terminal emulation within the cygwin dll. > Regarding those "trace thingies": > > The problem is that I'm experimenting with different versions of the > cygwin1.dll to see if I can find one which fixes some of the more serious > bugs without introducing new bugs. For example, the 5/23 dll fixes the > "find command broken across mounts" bug but breaks cat in the process. I > guess that's what's meant by a "stable" release -- a release which > introduces very few new bugs of its own while fixing a substantial number of > the bugs in previous releases. "Stable release"? Well all of the snapshots are ALPHA untested releases. If a user suggests that he is using a particular snapshot without much headache it doesn't mean that there aren't bugs. > > If I'm experimenting with every version of the dll after 5/23, trying to > find one which fixes the problems I'm experiencing, it's a real pain to have > to unpack the inst archive, too. I was hoping someone could tell me: "The > version released on, e.g. 6/10, fixes most of the reported bugs that have > been fixed so far and ***has not been reported to have introduced any > serious new bugs***". Then I could grab that version of the dll and the > inst archive and spend the time to install them with reasonable confidence > that I'll have a working system when I'm done ("working" means "with all the > goodies which have worked in the past but without major new bugs"). > If you're "experimenting" then you'd better have a "test plan" and a means of "fallback". NOTE: the cygwin-inst only contains binaries of importance to the maintenance and testing of the cygwin1.dll environment. Such things as mount, umount, cygwin1.dll, cygcheck, etc. and doesn't contain a full installation of pre-built binaries. The reason is that since the functions called from the cygwin1.dll are dynamic, then the binaries which use those functions don't need to be rebuilt to use the modified functions. Therefore, IMO, the "trace thingies" are not a result of incompatibility between libraries and binaries; but, merely an inconvenient bug. === Earnie Boyd < mailto:earnie_boyd@yahoo.com > Newbies, please visit < http://www.freeyellow.com/members5/gw32/index.html > (If you respond to the list, then please don't cc me) _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Earnie Boyd To: cygwin users Subject: RE: cat broken Date: Wed, 30 Jun 1999 22:10:00 -0000 Message-ID: <19990624175704.27192.rocketmail@web126.yahoomail.com> X-SW-Source: 1999-06n/msg00583.html Message-ID: <19990630221000.2yBRHjoJ7waWDOH0cAuXq-6KSkRU4hpwH6DDhbdRlA8@z> --- John Wiersba wrote: > Phil: OK, I see what you're saying now. > > What I was talking about was a duplicate echo. Not the normal echoing of > characters which you can turn on and off with stty, but a *second* copy of > the line you just typed which is echoed immediately after pressing the ENTER > key. > > cat > file > this is a test. (ENTER pressed here) > this is a test. > please stop repeating what I say (ENTER pressed here) > please stop repeating what I say > ... > > cat is broken in the 5/23 release, fixed in the 1/16 and 6/10 releases (I > don't know why). > Let's restate this: It isn't cat that is broken but the terminal emulation within the cygwin dll. > Regarding those "trace thingies": > > The problem is that I'm experimenting with different versions of the > cygwin1.dll to see if I can find one which fixes some of the more serious > bugs without introducing new bugs. For example, the 5/23 dll fixes the > "find command broken across mounts" bug but breaks cat in the process. I > guess that's what's meant by a "stable" release -- a release which > introduces very few new bugs of its own while fixing a substantial number of > the bugs in previous releases. "Stable release"? Well all of the snapshots are ALPHA untested releases. If a user suggests that he is using a particular snapshot without much headache it doesn't mean that there aren't bugs. > > If I'm experimenting with every version of the dll after 5/23, trying to > find one which fixes the problems I'm experiencing, it's a real pain to have > to unpack the inst archive, too. I was hoping someone could tell me: "The > version released on, e.g. 6/10, fixes most of the reported bugs that have > been fixed so far and ***has not been reported to have introduced any > serious new bugs***". Then I could grab that version of the dll and the > inst archive and spend the time to install them with reasonable confidence > that I'll have a working system when I'm done ("working" means "with all the > goodies which have worked in the past but without major new bugs"). > If you're "experimenting" then you'd better have a "test plan" and a means of "fallback". NOTE: the cygwin-inst only contains binaries of importance to the maintenance and testing of the cygwin1.dll environment. Such things as mount, umount, cygwin1.dll, cygcheck, etc. and doesn't contain a full installation of pre-built binaries. The reason is that since the functions called from the cygwin1.dll are dynamic, then the binaries which use those functions don't need to be rebuilt to use the modified functions. Therefore, IMO, the "trace thingies" are not a result of incompatibility between libraries and binaries; but, merely an inconvenient bug. === Earnie Boyd < mailto:earnie_boyd@yahoo.com > Newbies, please visit < http://www.freeyellow.com/members5/gw32/index.html > (If you respond to the list, then please don't cc me) _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com