RE: cat broken

RE: cat broken

[John Wiersba]

> -----Original Message-----
> From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> Sent: Thursday, June 24, 1999 1:57 PM
> To: cygwin users
> Subject: RE: cat broken

...<SNIP>...

> Let's restate this:  It isn't cat that is broken but the 
> terminal emulation
> within the cygwin dll.

OK, I believe this.  the cygwin dll terminal emulation is fixed in the 6/10
release.

> "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.

OK, I know this is still alpha or beta.  Obviously there are still bugs.
What I'm looking for is *relative* stability, not perfection.

> 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. 

If what you say is correct (and I'm hoping it is!), then I do have a "test
plan":  I simply throw away the broken version of cygwin1.dll and restore
the previous version.

> Therefore, IMO, 
> the "trace
> thingies" are not a result of incompatibility between 
> libraries and binaries;
> but, merely an inconvenient bug.

OK, then it appears that every snapshot since 5/24 has this bug in it.  I'm
not exactly sure why it is showing up so frequently in my environment.  I
saw this virtually every time when piping
   ls | grep | perl

Could these two bugs be related?  It seems that when the terminal emulation
bug went away, simultaneously the fhandler_base::fork_fixup bug appeared.

-- John

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: cat broken

[Chris Faylor]

On Thu, Jun 24, 1999 at 03:02:58PM -0400, John Wiersba wrote:
>OK, then it appears that every snapshot since 5/24 has this bug in it.  I'm
>not exactly sure why it is showing up so frequently in my environment.  I
>saw this virtually every time when piping
>   ls | grep | perl

You've actually tried every snapshot from 5/24 and 6/15?  Wow.  I can't
duplicate this problem, FWIW.  It works fine for me.

>Could these two bugs be related?  It seems that when the terminal emulation
>bug went away, simultaneously the fhandler_base::fork_fixup bug appeared.

Probably not.

-chris

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: cat broken

[John Wiersba]

> -----Original Message-----
> From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> Sent: Thursday, June 24, 1999 1:57 PM
> To: cygwin users
> Subject: RE: cat broken

...<SNIP>...

> Let's restate this:  It isn't cat that is broken but the 
> terminal emulation
> within the cygwin dll.

OK, I believe this.  the cygwin dll terminal emulation is fixed in the 6/10
release.

> "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.

OK, I know this is still alpha or beta.  Obviously there are still bugs.
What I'm looking for is *relative* stability, not perfection.

> 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. 

If what you say is correct (and I'm hoping it is!), then I do have a "test
plan":  I simply throw away the broken version of cygwin1.dll and restore
the previous version.

> Therefore, IMO, 
> the "trace
> thingies" are not a result of incompatibility between 
> libraries and binaries;
> but, merely an inconvenient bug.

OK, then it appears that every snapshot since 5/24 has this bug in it.  I'm
not exactly sure why it is showing up so frequently in my environment.  I
saw this virtually every time when piping
   ls | grep | perl

Could these two bugs be related?  It seems that when the terminal emulation
bug went away, simultaneously the fhandler_base::fork_fixup bug appeared.

-- John

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: cat broken

[Chris Faylor]

On Thu, Jun 24, 1999 at 03:02:58PM -0400, John Wiersba wrote:
>OK, then it appears that every snapshot since 5/24 has this bug in it.  I'm
>not exactly sure why it is showing up so frequently in my environment.  I
>saw this virtually every time when piping
>   ls | grep | perl

You've actually tried every snapshot from 5/24 and 6/15?  Wow.  I can't
duplicate this problem, FWIW.  It works fine for me.

>Could these two bugs be related?  It seems that when the terminal emulation
>bug went away, simultaneously the fhandler_base::fork_fixup bug appeared.

Probably not.

-chris

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: cat broken

[Earnie Boyd]

--- John Wiersba <John.Wiersba@medstat.com> 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

cat broken

[John Wiersba]

Using the 5/23 cygwin1.dll, the following is broken:
	cat >file
It echos the input typed from the terminal and refuses to accept ^D as EOF.
I have CYGWIN=tty among other things.  Is there a more recent version of the
dll with this bug fixed?  The 1/15 cygwin1.dll doesn't have this problem.
(However, I'm still using the cat.exe from 1/15 -- could this be the
problem?

-- John

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: cat broken

[Phil Edwards]

> > > Using the 5/23 cygwin1.dll, the following is broken:
> > > 	cat >file
> > > It echos the input typed from the terminal
> > 
> > Uh, that's what is supposed to happen... unless you mean that it ONLY
> > echos the input, and writes a zero-length file?
>
> No, "cat >file" should take input from stdin (the terminal) and write it to
> file, which in fact is what happens with the 1/15 cygwin1.dll.  However, the
> 5/23 dll echos the input from terminal back to the terminal.

Let me try again.  On any and every Unix,

   $ cat > file
   This is a test.
   ^D
   $ 

should echo to the screen as well as write to the file.  You will be hard
pressed to not get that stuff echoed on the screen.  I'm /hoping/ that your
problem is that cat is /only/ echoing to the screen and not /also/ writing
a file.  Check?


Now, the errors that you're seeing after replacing the DLL (those freaky
trace thingies) are indeed due to a mismatch between a binary and the DLL.
That's the only major problem with using the inst snapshots; it's harder
to keep things in sync (e.g., backing out replacements, or not getting a
new binary with a new DLL).  How you as an end user manage that is largely
a matter of taste -- copying directory structures and updating a copy, or
reinstalling original binaries from a distribution, or just living with
the nonfatal errors, etc, etc.


(If you reply to the list, please DON'T cc another copy to me.  Thanks!)
Phil


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: cat broken

[Dr. Volker Zell]

>>>>> "John" == John Wiersba <John.Wiersba@medstat.com> writes:

    John> I tried the 6/10 dll.  It fixed the cat problem.  But now I
    John> frequently get the following error message: 0 0 [main]
    John> D:\opt\cygwin\bin\bash.exe 1008 fhandler_base::fork_fixup:
    John> /jrw/jrw/mdst/sh/d - Win32 error 6, handle 0x30

    John> Is this caused by a mismatch in bash.exe (dated 12/1/98)
    John> vs. cygwin1.dll?  Do I have to install everything in the
    John> 6/10 cygwin-inst*, too?  That's more dangerous because it's
    John> harder to back out.

I installed only the dll. My CYGWIN env liks like:

System:   WinNT 4.0/SP3
          Cygwin B20.1 with egcs-1.1.2
           - cygwin1.dll - cygwin1-19990610.dll.gz
           - everything mounted binary,
           - CYGWIN = tty title binmode ntea nontsec


Ciao
  Volker


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: cat broken

[Dr. Volker Zell]

>>>>> "John" == John Wiersba <John.Wiersba@medstat.com> writes:

    John> Using the 5/23 cygwin1.dll, the following is broken: cat
    John> >file It echos the input typed from the terminal and refuses
    John> to accept ^D as EOF.  I have CYGWIN=tty among other things.
    John> Is there a more recent version of the dll with this bug
    John> fixed?  The 1/15 cygwin1.dll doesn't have this problem.

Try 6/10, this works.

Ciao
  Volker


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: cat broken

[John Wiersba]

Actually, I tried a sample of the snapshots I found on
ftp://go.cygnus.com/pub/sourceware.cygnus.com/cygwin/snapshots/ from the
following list of dates:
0523 0524 0526 0528 0529 0530 0531 0601 0602 0603 0604 0605 0607 0608 0610
0612 0614 0615

I assumed that if it failed at the endpoints and also in the middle that it
failed everywhere.  After reading your email, I thought maybe I'd go out and
try every one.  It appears that the snapshot on 5/28 does *not* have the
fhandler_base::fork_fixup bug.  Thanks for spurring me on!
Hopefully, 5/28 doesn't have any other new major bugs, either.

-- John

> -----Original Message-----
> From: Chris Faylor [ mailto:cygwin@sourceware.cygnus.com ]
> Sent: Thursday, June 24, 1999 3:13 PM
> To: John Wiersba
> Cc: cygwin users
> Subject: Re: cat broken
> 
> 
> On Thu, Jun 24, 1999 at 03:02:58PM -0400, John Wiersba wrote:
> >OK, then it appears that every snapshot since 5/24 has this 
> bug in it.  I'm
> >not exactly sure why it is showing up so frequently in my 
> environment.  I
> >saw this virtually every time when piping
> >   ls | grep | perl
> 
> You've actually tried every snapshot from 5/24 and 6/15?  
> Wow.  I can't
> duplicate this problem, FWIW.  It works fine for me.
> 
> >Could these two bugs be related?  It seems that when the 
> terminal emulation
> >bug went away, simultaneously the   
> bug appeared.
> 
> Probably not.
> 
> -chris
> 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: cat broken

[Chris Faylor]

On Thu, Jun 24, 1999 at 11:18:15AM -0400, John Wiersba wrote:
>I tried the 6/10 dll.  It fixed the cat problem.  But now I frequently get
>the following error message:
>    0       0 [main] D:\opt\cygwin\bin\bash.exe 1008
>fhandler_base::fork_fixup: /jrw/jrw/mdst/sh/d - Win32 error 6, handle 0x30
>
>Is this caused by a mismatch in bash.exe (dated 12/1/98) vs.
>cygwin1.dll?  Do I have to install everything in the 6/10 cygwin-inst*,
>too?  That's more dangerous because it's harder to back out.

There is never going to be a mismatch between a newer "cygwin1" DLL and
an older binary.  What you're seeing is undoubtedly a bug in that
snapshot.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: cat broken

[John Wiersba]

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).

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.  

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").

-- John

> -----Original Message-----
> From: Phil Edwards [ mailto:pedwards@jaj.com ]
> Sent: Thursday, June 24, 1999 12:48 PM
> To: cygwin@sourceware.cygnus.com; John.Wiersba@medstat.com
> Subject: RE: cat broken
> 
> 
> 
> 
> > > > Using the 5/23 cygwin1.dll, the following is broken:
> > > > 	cat >file
> > > > It echos the input typed from the terminal
> > > 
> > > Uh, that's what is supposed to happen... unless you mean 
> that it ONLY
> > > echos the input, and writes a zero-length file?
> >
> > No, "cat >file" should take input from stdin (the terminal) 
> and write it to
> > file, which in fact is what happens with the 1/15 
> cygwin1.dll.  However, the
> > 5/23 dll echos the input from terminal back to the terminal.
> 
> Let me try again.  On any and every Unix,
> 
>    $ cat > file
>    This is a test.
>    ^D
>    $ 
> 
> should echo to the screen as well as write to the file.  You 
> will be hard
> pressed to not get that stuff echoed on the screen.  I'm 
> /hoping/ that your
> problem is that cat is /only/ echoing to the screen and not 
> /also/ writing
> a file.  Check?
> 
> 
> Now, the errors that you're seeing after replacing the DLL 
> (those freaky
> trace thingies) are indeed due to a mismatch between a binary 
> and the DLL.
> That's the only major problem with using the inst snapshots; 
> it's harder
> to keep things in sync (e.g., backing out replacements, or 
> not getting a
> new binary with a new DLL).  How you as an end user manage 
> that is largely
> a matter of taste -- copying directory structures and 
> updating a copy, or
> reinstalling original binaries from a distribution, or just 
> living with
> the nonfatal errors, etc, etc.
> 
> 
> (If you reply to the list, please DON'T cc another copy to 
> me.  Thanks!)
> Phil
> 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: cat broken

[John Wiersba]

I tried the 6/10 dll.  It fixed the cat problem.  But now I frequently get
the following error message:
    0       0 [main] D:\opt\cygwin\bin\bash.exe 1008
fhandler_base::fork_fixup: /jrw/jrw/mdst/sh/d - Win32 error 6, handle 0x30

Is this caused by a mismatch in bash.exe (dated 12/1/98) vs. cygwin1.dll?
Do I have to install everything in the 6/10 cygwin-inst*, too?  That's more
dangerous because it's harder to back out.

-- John
 
> -----Original Message-----
> From: Dr. Volker Zell [ mailto:vzell@de.oracle.com ]
> Sent: Thursday, June 24, 1999 3:52 AM
> To: John Wiersba
> Cc: cygwin newsgroup
> Subject: Re: cat broken
> 
> 
> >>>>> "John" == John Wiersba <John.Wiersba@medstat.com> writes:
> 
>     John> Using the 5/23 cygwin1.dll, the following is broken: cat
>     John> >file It echos the input typed from the terminal and refuses
>     John> to accept ^D as EOF.  I have CYGWIN=tty among other things.
>     John> Is there a more recent version of the dll with this bug
>     John> fixed?  The 1/15 cygwin1.dll doesn't have this problem.
> 
> Try 6/10, this works.
> 
> Ciao
>   Volker
> 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: cat broken

[Phil Edwards]

> Using the 5/23 cygwin1.dll, the following is broken:
> 	cat >file
> It echos the input typed from the terminal

Uh, that's what is supposed to happen... unless you mean that it ONLY
echos the input, and writes a zero-length file?


> and refuses to accept ^D as EOF.

Use ^Z<CR> (i.e., pretend you had typed COPY CON FILE instead).  This
is just a hack.


> I have CYGWIN=tty among other things.

I honestly don't know whether this would affect things or not.  The
above is what I have to do with an out-of-box B20, no cat.exe or DLL
or CYGWIN= changes.

Luck++;

(If you reply to the list, please don't cc another copy to me.  Thanks!)
Phil


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: cat broken

[John Wiersba]

> > Using the 5/23 cygwin1.dll, the following is broken:
> > 	cat >file
> > It echos the input typed from the terminal
> 
> Uh, that's what is supposed to happen... unless you mean that it ONLY
> echos the input, and writes a zero-length file?

No, "cat >file" should take input from stdin (the terminal) and write it to
file, which in fact is what happens with the 1/15 cygwin1.dll.  However, the
5/23 dll echos the input from terminal back to the terminal.

> > and refuses to accept ^D as EOF.
> 
> Use ^Z<CR> (i.e., pretend you had typed COPY CON FILE instead).  This
> is just a hack.

I can try ^Z, but, again, the 1/15 dll works properly, taking a ^D as EOF.

-- John

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: cat broken

[John Wiersba]

Actually, I tried a sample of the snapshots I found on
ftp://go.cygnus.com/pub/sourceware.cygnus.com/cygwin/snapshots/ from the
following list of dates:
0523 0524 0526 0528 0529 0530 0531 0601 0602 0603 0604 0605 0607 0608 0610
0612 0614 0615

I assumed that if it failed at the endpoints and also in the middle that it
failed everywhere.  After reading your email, I thought maybe I'd go out and
try every one.  It appears that the snapshot on 5/28 does *not* have the
fhandler_base::fork_fixup bug.  Thanks for spurring me on!
Hopefully, 5/28 doesn't have any other new major bugs, either.

-- John

> -----Original Message-----
> From: Chris Faylor [ mailto:cygwin@sourceware.cygnus.com ]
> Sent: Thursday, June 24, 1999 3:13 PM
> To: John Wiersba
> Cc: cygwin users
> Subject: Re: cat broken
> 
> 
> On Thu, Jun 24, 1999 at 03:02:58PM -0400, John Wiersba wrote:
> >OK, then it appears that every snapshot since 5/24 has this 
> bug in it.  I'm
> >not exactly sure why it is showing up so frequently in my 
> environment.  I
> >saw this virtually every time when piping
> >   ls | grep | perl
> 
> You've actually tried every snapshot from 5/24 and 6/15?  
> Wow.  I can't
> duplicate this problem, FWIW.  It works fine for me.
> 
> >Could these two bugs be related?  It seems that when the 
> terminal emulation
> >bug went away, simultaneously the   
> bug appeared.
> 
> Probably not.
> 
> -chris
> 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: cat broken

[Chris Faylor]

On Thu, Jun 24, 1999 at 11:18:15AM -0400, John Wiersba wrote:
>I tried the 6/10 dll.  It fixed the cat problem.  But now I frequently get
>the following error message:
>    0       0 [main] D:\opt\cygwin\bin\bash.exe 1008
>fhandler_base::fork_fixup: /jrw/jrw/mdst/sh/d - Win32 error 6, handle 0x30
>
>Is this caused by a mismatch in bash.exe (dated 12/1/98) vs.
>cygwin1.dll?  Do I have to install everything in the 6/10 cygwin-inst*,
>too?  That's more dangerous because it's harder to back out.

There is never going to be a mismatch between a newer "cygwin1" DLL and
an older binary.  What you're seeing is undoubtedly a bug in that
snapshot.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: cat broken

[Earnie Boyd]

--- John Wiersba <John.Wiersba@medstat.com> 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

RE: cat broken

[John Wiersba]

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).

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.  

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").

-- John

> -----Original Message-----
> From: Phil Edwards [ mailto:pedwards@jaj.com ]
> Sent: Thursday, June 24, 1999 12:48 PM
> To: cygwin@sourceware.cygnus.com; John.Wiersba@medstat.com
> Subject: RE: cat broken
> 
> 
> 
> 
> > > > Using the 5/23 cygwin1.dll, the following is broken:
> > > > 	cat >file
> > > > It echos the input typed from the terminal
> > > 
> > > Uh, that's what is supposed to happen... unless you mean 
> that it ONLY
> > > echos the input, and writes a zero-length file?
> >
> > No, "cat >file" should take input from stdin (the terminal) 
> and write it to
> > file, which in fact is what happens with the 1/15 
> cygwin1.dll.  However, the
> > 5/23 dll echos the input from terminal back to the terminal.
> 
> Let me try again.  On any and every Unix,
> 
>    $ cat > file
>    This is a test.
>    ^D
>    $ 
> 
> should echo to the screen as well as write to the file.  You 
> will be hard
> pressed to not get that stuff echoed on the screen.  I'm 
> /hoping/ that your
> problem is that cat is /only/ echoing to the screen and not 
> /also/ writing
> a file.  Check?
> 
> 
> Now, the errors that you're seeing after replacing the DLL 
> (those freaky
> trace thingies) are indeed due to a mismatch between a binary 
> and the DLL.
> That's the only major problem with using the inst snapshots; 
> it's harder
> to keep things in sync (e.g., backing out replacements, or 
> not getting a
> new binary with a new DLL).  How you as an end user manage 
> that is largely
> a matter of taste -- copying directory structures and 
> updating a copy, or
> reinstalling original binaries from a distribution, or just 
> living with
> the nonfatal errors, etc, etc.
> 
> 
> (If you reply to the list, please DON'T cc another copy to 
> me.  Thanks!)
> Phil
> 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: cat broken

[Phil Edwards]

> > > Using the 5/23 cygwin1.dll, the following is broken:
> > > 	cat >file
> > > It echos the input typed from the terminal
> > 
> > Uh, that's what is supposed to happen... unless you mean that it ONLY
> > echos the input, and writes a zero-length file?
>
> No, "cat >file" should take input from stdin (the terminal) and write it to
> file, which in fact is what happens with the 1/15 cygwin1.dll.  However, the
> 5/23 dll echos the input from terminal back to the terminal.

Let me try again.  On any and every Unix,

   $ cat > file
   This is a test.
   ^D
   $ 

should echo to the screen as well as write to the file.  You will be hard
pressed to not get that stuff echoed on the screen.  I'm /hoping/ that your
problem is that cat is /only/ echoing to the screen and not /also/ writing
a file.  Check?


Now, the errors that you're seeing after replacing the DLL (those freaky
trace thingies) are indeed due to a mismatch between a binary and the DLL.
That's the only major problem with using the inst snapshots; it's harder
to keep things in sync (e.g., backing out replacements, or not getting a
new binary with a new DLL).  How you as an end user manage that is largely
a matter of taste -- copying directory structures and updating a copy, or
reinstalling original binaries from a distribution, or just living with
the nonfatal errors, etc, etc.


(If you reply to the list, please DON'T cc another copy to me.  Thanks!)
Phil


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: cat broken

[Dr. Volker Zell]

>>>>> "John" == John Wiersba <John.Wiersba@medstat.com> writes:

    John> I tried the 6/10 dll.  It fixed the cat problem.  But now I
    John> frequently get the following error message: 0 0 [main]
    John> D:\opt\cygwin\bin\bash.exe 1008 fhandler_base::fork_fixup:
    John> /jrw/jrw/mdst/sh/d - Win32 error 6, handle 0x30

    John> Is this caused by a mismatch in bash.exe (dated 12/1/98)
    John> vs. cygwin1.dll?  Do I have to install everything in the
    John> 6/10 cygwin-inst*, too?  That's more dangerous because it's
    John> harder to back out.

I installed only the dll. My CYGWIN env liks like:

System:   WinNT 4.0/SP3
          Cygwin B20.1 with egcs-1.1.2
           - cygwin1.dll - cygwin1-19990610.dll.gz
           - everything mounted binary,
           - CYGWIN = tty title binmode ntea nontsec


Ciao
  Volker


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: cat broken

[John Wiersba]

I tried the 6/10 dll.  It fixed the cat problem.  But now I frequently get
the following error message:
    0       0 [main] D:\opt\cygwin\bin\bash.exe 1008
fhandler_base::fork_fixup: /jrw/jrw/mdst/sh/d - Win32 error 6, handle 0x30

Is this caused by a mismatch in bash.exe (dated 12/1/98) vs. cygwin1.dll?
Do I have to install everything in the 6/10 cygwin-inst*, too?  That's more
dangerous because it's harder to back out.

-- John
 
> -----Original Message-----
> From: Dr. Volker Zell [ mailto:vzell@de.oracle.com ]
> Sent: Thursday, June 24, 1999 3:52 AM
> To: John Wiersba
> Cc: cygwin newsgroup
> Subject: Re: cat broken
> 
> 
> >>>>> "John" == John Wiersba <John.Wiersba@medstat.com> writes:
> 
>     John> Using the 5/23 cygwin1.dll, the following is broken: cat
>     John> >file It echos the input typed from the terminal and refuses
>     John> to accept ^D as EOF.  I have CYGWIN=tty among other things.
>     John> Is there a more recent version of the dll with this bug
>     John> fixed?  The 1/15 cygwin1.dll doesn't have this problem.
> 
> Try 6/10, this works.
> 
> Ciao
>   Volker
> 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: cat broken

[Dr. Volker Zell]

>>>>> "John" == John Wiersba <John.Wiersba@medstat.com> writes:

    John> Using the 5/23 cygwin1.dll, the following is broken: cat
    John> >file It echos the input typed from the terminal and refuses
    John> to accept ^D as EOF.  I have CYGWIN=tty among other things.
    John> Is there a more recent version of the dll with this bug
    John> fixed?  The 1/15 cygwin1.dll doesn't have this problem.

Try 6/10, this works.

Ciao
  Volker


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: cat broken

[John Wiersba]

> > Using the 5/23 cygwin1.dll, the following is broken:
> > 	cat >file
> > It echos the input typed from the terminal
> 
> Uh, that's what is supposed to happen... unless you mean that it ONLY
> echos the input, and writes a zero-length file?

No, "cat >file" should take input from stdin (the terminal) and write it to
file, which in fact is what happens with the 1/15 cygwin1.dll.  However, the
5/23 dll echos the input from terminal back to the terminal.

> > and refuses to accept ^D as EOF.
> 
> Use ^Z<CR> (i.e., pretend you had typed COPY CON FILE instead).  This
> is just a hack.

I can try ^Z, but, again, the 1/15 dll works properly, taking a ^D as EOF.

-- John

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: cat broken

[Phil Edwards]

> Using the 5/23 cygwin1.dll, the following is broken:
> 	cat >file
> It echos the input typed from the terminal

Uh, that's what is supposed to happen... unless you mean that it ONLY
echos the input, and writes a zero-length file?


> and refuses to accept ^D as EOF.

Use ^Z<CR> (i.e., pretend you had typed COPY CON FILE instead).  This
is just a hack.


> I have CYGWIN=tty among other things.

I honestly don't know whether this would affect things or not.  The
above is what I have to do with an out-of-box B20, no cat.exe or DLL
or CYGWIN= changes.

Luck++;

(If you reply to the list, please don't cc another copy to me.  Thanks!)
Phil


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

cat broken

[John Wiersba]

Using the 5/23 cygwin1.dll, the following is broken:
	cat >file
It echos the input typed from the terminal and refuses to accept ^D as EOF.
I have CYGWIN=tty among other things.  Is there a more recent version of the
dll with this bug fixed?  The 1/15 cygwin1.dll doesn't have this problem.
(However, I'm still using the cat.exe from 1/15 -- could this be the
problem?

-- John

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com