Re: getc() problem with Cygwin v1.0

Re: getc() problem with Cygwin v1.0

[Earnie Boyd]

--- Dtcohen@aol.com wrote:
-8<-
> Chris, Ernie, et al,
> 
>      OK, we're probably getting closer but I tried setting CYGWIN=tty
> in Control Panel -> System -> Environment, (and then re-starting bash) and
> unfortunately we're not quite there yet (I'm having the same problems).
> 
>      I also tried setting CYGWIN32=tty and CYGWIN_TTY=1 (just because I
> found them set on my B20.1 system) and still no luck.  And just to be sure
> I also tried setting them all in my AUTOEXEC.BAT (even though I'm running NT)
> and my .bashrc (even though the instructions say that it must be set BEFORE
> the shell is running); still no success.
> 
>      As per Ernie's suggestion I have included a paste of cygcheck -r -s -v.
> I hope this helps.  Please get back to me with any more suggestios.
> 
>      P.S. sorry if it takes a day for me to respond.  My v1.0 system is at
> home...
> 
> Many thanks,
> Jim Grishaw
> dtcohen@aol.com
> 
> ----------------------- Paste of "cygcheck -r -s -v"
> -------------------------
> 
> 
> Cygnus Win95/NT Configuration Diagnostics
> Current System Time: Fri Jan 14 10:28:37 2000
> 
> WinNT Ver 4.0 build 1381 Service Pack 3
> 
> Path:   /cygdrive/d/grishaw/bin
>     /bin

As always, /bin should be first in the PATH, but that isn't going to solve your
problem.

>     /contrib/bin
>     /usr/i686-cygwin/bin
>     /usr/local/bin
>     /usr/local/bin/X11
>     /usr/X11R6/bin
>     /usr/lib/gcc-lib/i686-cygwin/2.9-cygwin-990830
>     /cygdrive/d/ModelTech/win32
>     /cygdrive/c/WINNT/SYSTEM32
>     /cygdrive/c/WINNT
> 
> SysDir: C:\WINNT\System32
> WinDir: C:\WINNT
> 
> CYGWIN32 = `tty'
> CYGWIN = `tty'
> HOME = `/cygdrive/d/grishaw'
> PWD = `//D/grishaw'
> 
-8<-
> TEMP = `C:\TEMP'
> TERM = `ansi'

Try `export TERM=cygwin'.  Yea, I know Chris said that it shouldn't matter.

Hmm... I just did `export TERM=ansi' and I can still do the backspace.  What
happens if you do Ctrl-H instead of the Backspace key?  Is it possible that
your Backspace key is mapped to be the Delete key?  BTW, my CYGWIN variable
isn't set at all.

Regards,

=====
Earnie Boyd < mailto:earnie_boyd@yahoo.com >
Cygwin Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

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

Re: getc() problem with Cygwin v1.0

[Chris Faylor]

On Fri, Jan 14, 2000 at 11:50:46AM -0800, Earnie Boyd wrote:
>Try `export TERM=cygwin'.  Yea, I know Chris said that it shouldn't matter.
>
>Hmm... I just did `export TERM=ansi' and I can still do the backspace.  What
>happens if you do Ctrl-H instead of the Backspace key?  Is it possible that
>your Backspace key is mapped to be the Delete key?  BTW, my CYGWIN variable
>isn't set at all.

I thought that I'd responded to this already but I can't find it in my mail
logs.

There is a bug in the handling of "cooked" mode in cygwin 1.0 iff you are
using CYGWIN=tty.  There is no workaround other than to download a snapshot.

cgf

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

RE: getc() problem with Cygwin v1.0

[Fifer, Eric]

Chris Faylor writes:
>If I understand what you're saying, you are able to get line
>editing inside of, say, "cat", right?  If so, I will apply
>this patch.

Yes, exactly.

Thanks.

Eric

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

Re: getc() problem with Cygwin v1.0

['Chris Faylor']

Hmm.  I don't know if there is a better way to do this.  This
patch may be fine.

If I understand what you're saying, you are able to get line
editing inside of, say, "cat", right?  If so, I will apply
this patch.

Thanks for tracking this down.

cgf

On Tue, Jan 18, 2000 at 06:07:07PM -0000, Fifer, Eric wrote:
>
>Jim Grishaw writes:
>>     Thanks for the post.  I would suggest un-setting your CYGWIN=tty
>>variable and see if you still have the problem.
>
>Thanks, but since I'm using a recent snapshot (2000-Jan-14) what I'm
>seeing must be different.  The value of "tty" in CYGWIN did not
>affect the problem I reported.  Again, what I am seeing is that
>line editing works when running inside a console, but within
>rxvt line editing does not work.
>
>After poking around in the source, I was able to make a patch that
>fixes the problem I'm having.  I won't be surprised if there is a
>better way of doing this, but this does fix the problem:
>
>--- fhandler_tty.cc.orig        Tue Jan 18 17:41:18 2000
>+++ fhandler_tty.cc     Tue Jan 18 17:38:07 2000
>@@ -885,7 +885,7 @@
> int
> fhandler_pty_master::write (const void *ptr, size_t len)
> {
>-  line_edit ((char *) ptr, len, 1);
>+  line_edit ((char *) ptr, len /*, 1*/);
>   return len;
> }
>
>Having always_accept (the 3rd arg to line_edit) set to 1 prevents
>pseudo-terminals from having line editing.  I'm not sure what was
>intended here.

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

RE: getc() problem with Cygwin v1.0

[Fifer, Eric]

Jim Grishaw writes:
>     Thanks for the post.  I would suggest un-setting your CYGWIN=tty
>variable and see if you still have the problem.

Thanks, but since I'm using a recent snapshot (2000-Jan-14) what I'm
seeing must be different.  The value of "tty" in CYGWIN did not
affect the problem I reported.  Again, what I am seeing is that
line editing works when running inside a console, but within
rxvt line editing does not work.

After poking around in the source, I was able to make a patch that
fixes the problem I'm having.  I won't be surprised if there is a
better way of doing this, but this does fix the problem:

--- fhandler_tty.cc.orig        Tue Jan 18 17:41:18 2000
+++ fhandler_tty.cc     Tue Jan 18 17:38:07 2000
@@ -885,7 +885,7 @@
 int
 fhandler_pty_master::write (const void *ptr, size_t len)
 {
-  line_edit ((char *) ptr, len, 1);
+  line_edit ((char *) ptr, len /*, 1*/);
   return len;
 }

Having always_accept (the 3rd arg to line_edit) set to 1 prevents
pseudo-terminals from having line editing.  I'm not sure what was
intended here.

Eric Fifer


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

Re: getc() problem with Cygwin v1.0

[Dtcohen]

Earnie Boyd writes...
>Hmm... I just did `export TERM=ansi' and I can still do the backspace.  What
>happens if you do Ctrl-H instead of the Backspace key?  Is it possible that
>your Backspace key is mapped to be the Delete key?  BTW, my CYGWIN variable
>isn't set at all.
>
>Regards,
>
>=====
>Earnie Boyd

Chris Faylor writes...
>I thought that I'd responded to this already but I can't find it in my mail
>logs.
>
>There is a bug in the handling of "cooked" mode in cygwin 1.0 iff you are
>using CYGWIN=tty.  There is no workaround other than to download a snapshot.
>
>cgf

OK, now we're talking.  I unset my CYGWIN variable and now everything
works fine.

Thanks everyone for your help with this one.

From Eric Fifer...
>
>I'm not sure this is related, but I posted about something
>similar a few weeks back (and had no responses).  I'm not
>running v1.0, right now I'm running the 2000/01/05 snapshot
>and the following is still true ...
>
>---
>
>Subject: line editing not working with rxvt and recent cygwin snapshots
>
>Line editing (erase/kill) isn't working within rxvt.  I'm not
>sure why, but characters are being processed immediately.
>
>It's easy to demonstrate, start up "cat" reading from stdin and then
>just type "abc ENTER".
>
>In the normal console you'll see:
>
>        bash$ cat
>        abc
>        abc
>
>In rxvt:
>
>        bash$ cat
>        aabbcc
>
>With my old b20.1 setup, rxvt and line editing works fine.
>
>For the test, I forced my stty settings to be identical
>on both ttys.  And CYGWIN does set "tty".
>

Eric,

     Thanks for the post.  I would suggest un-setting your CYGWIN=tty
variable and see if you still have the problem.

Jim Grishaw.
dtcohen@aol.com

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

Re: getc() problem with Cygwin v1.0

[Dtcohen]

>
>I'm not sure this is related, but I posted about something
>similar a few weeks back (and had no responses).  I'm not
>running v1.0, right now I'm running the 2000/01/05 snapshot
>and the following is still true ...
>
>---
>
>Subject: line editing not working with rxvt and recent cygwin snapshots
>
>Line editing (erase/kill) isn't working within rxvt.  I'm not
>sure why, but characters are being processed immediately.
>
>It's easy to demonstrate, start up "cat" reading from stdin and then
>just type "abc ENTER".
>
>In the normal console you'll see:
>
>        bash$ cat
>        abc
>        abc
>
>In rxvt:
>
>        bash$ cat
>        aabbcc
>
>With my old b20.1 setup, rxvt and line editing works fine.
>
>For the test, I forced my stty settings to be identical
>on both ttys.  And CYGWIN does set "tty".
>
>Unfortunately, I can't really strace the process when
>running under rxvt, because the strace pops open a normal
>console window for ttyin/ttyout and then everything works.
>
>Any ideas on how to track this down?  Some kind of difference
>between pseudo-terminals and console-terminals?
>
>Thanks.
>
>Eric Fifer
>

Eric,

     Thanks for the post.  Looks like the same problem I'm seeing.
I'm willing to spend some time tracking this down but unfortunately I don't
have a clue where to start...

Jim Grishaw.
dtcohen@aol.com

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

RE: getc() problem with Cygwin v1.0

[Fifer, Eric]

>Unfortunately, I can't really strace the process when
>running under rxvt, because the strace pops open a normal
>console window for ttyin/ttyout and then everything works.

I take this back (it must have been an earlier snapshot).
On a console, strace gives me this:

  [...]
  176  815887 [main] cat 1159 _read: read (0, 0xA04C578, 1024)
[[it blocks here and type in abc<ENTER>]]
  215 3501520 [main] cat 1159 peek_pipe: {stdin}, ready for read
  203 3502507 [main] cat 1159 fhandler_base::read: read 4 bytes ( a b c 0xA)
  197 3502704 [main] cat 1159 read_handler: 4 = read (0<{stdin}>, 0xA04C578,
1024)
  177 3503615 [main] cat 1159 _write: write (1, 0xA04C578, 4)
abc
  209 3503824 [main] cat 1159 fhandler_base::write: after write, name some
disk file, rpos 4
  200 3504024 [main] cat 1159 _write: 4 = write (1, 0xA04C578, 4)
  174 3504916 [main] cat 1159 _read: read (0, 0xA04C578, 1024)
[[and then blocks again]]

Within rxvt, strace gives me this:

  [...]
  175  830016 [main] cat 1251 _read: read (0, 0xA04BE80, 1024)
[[it blocks here, type a and it continues]]
  217 1182695 [main] cat 1251 peek_pipe: {stdin}, ready for read
  204 1183655 [main] cat 1251 fhandler_base::read: read 1 bytes ( a)
  195 1183850 [main] cat 1251 read_handler: 1 = read (0<{stdin}>, 0xA04BE80,
1024)
  175 1184745 [main] cat 1251 _write: write (1, 0xA04BE80, 1)
a  204 1184949 [main] cat 1251 fhandler_base::write: after write, name some
diskfile, rpos 1
  200 1185149 [main] cat 1251 _write: 1 = write (1, 0xA04BE80, 1)
  175 1186042 [main] cat 1251 _read: read (0, 0xA04BE80, 1024)
[[then blocks here, type b and it continues]]
  220 1823033 [main] cat 1251 peek_pipe: {stdin}, ready for read
  206 1823986 [main] cat 1251 fhandler_base::read: read 1 bytes ( b)
  196 1824182 [main] cat 1251 read_handler: 1 = read (0<{stdin}>, 0xA04BE80,
1024)
  176 1825080 [main] cat 1251 _write: write (1, 0xA04BE80, 1)
b  207 1825287 [main] cat 1251 fhandler_base::write: after write, name some
diskfile, rpos 2
  198 1825485 [main] cat 1251 _write: 1 = write (1, 0xA04BE80, 1)
  174 1826375 [main] cat 1251 _read: read (0, 0xA04BE80, 1024)
[etc ...]

But, this was only slightly useful once I started looking at the source.
And, right now I don't have the time to look any further ...

Eric Fifer

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

RE: getc() problem with Cygwin v1.0

[Fifer, Eric]

I'm not sure this is related, but I posted about something
similar a few weeks back (and had no responses).  I'm not
running v1.0, right now I'm running the 2000/01/05 snapshot
and the following is still true ...

---

Subject: line editing not working with rxvt and recent cygwin snapshots

Line editing (erase/kill) isn't working within rxvt.  I'm not
sure why, but characters are being processed immediately.

It's easy to demonstrate, start up "cat" reading from stdin and then
just type "abc ENTER".

In the normal console you'll see:

	bash$ cat
	abc
	abc

In rxvt:

	bash$ cat
	aabbcc

With my old b20.1 setup, rxvt and line editing works fine.

For the test, I forced my stty settings to be identical
on both ttys.  And CYGWIN does set "tty".

Unfortunately, I can't really strace the process when
running under rxvt, because the strace pops open a normal
console window for ttyin/ttyout and then everything works.

Any ideas on how to track this down?  Some kind of difference
between pseudo-terminals and console-terminals?

Thanks.

Eric Fifer

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

Re: getc() problem with Cygwin v1.0

[Christopher Faylor]

On Thu, Jan 13, 2000 at 12:10:03PM -0800, Earnie Boyd wrote:
>--- Dtcohen@aol.com wrote:
>-8<-
>> Yes, using gets() or fgets() for a small program would work better, but
>> the real problem is that canonical mode is broken for v1.0 (the man
>> page for "termio" explains this in detail, but it basically means getc(stdin)
>> should block until a carriage return is entered).  Canonical mode also
>> allows the user to backspace over his mistakes -- which also doesn't work
>> with v1.0.
>> 
>> Pre-compiled programs distributed with Cygwin v1.0 such as bc.exe, dc.exe,
>> etc all rely on canonical mode.  It is especially annoying to not be able
>> to backspace over my mistakes with dc.exe -- I have to kill the program
>> each time and start over.  Even if I were to modify the souce code to
>> replace getc(stdin) with fgets(...), I still wouldn't be able to backspace...
>> 
>> And for that matter, you can't backspace with sh.exe, either.  I can't
>> believe I'm the first person to notice this.
>> 
>> Hey Cygnus, are you reading this?  Is there any way we can fix canonical
>> mode for v1.0?
>> 
>
>Uhm... you've got something not set correctly.  What is your TERM variable set
>to?  It should read TERM=cygwin.  A paste of the output of `cygcheck -s -v -r'
>would be helpful.

The TERM setting should be irrelevant to this.  However, if it isn't set, it
will default to cygwin.

The TERM setting does not affect the default handling of canonical mode
in either UNIX or cygwin.

cgf

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

Re: getc() problem with Cygwin v1.0

[Earnie Boyd]

--- Dtcohen@aol.com wrote:
-8<-
> Yes, using gets() or fgets() for a small program would work better, but
> the real problem is that canonical mode is broken for v1.0 (the man
> page for "termio" explains this in detail, but it basically means getc(stdin)
> should block until a carriage return is entered).  Canonical mode also
> allows the user to backspace over his mistakes -- which also doesn't work
> with v1.0.
> 
> Pre-compiled programs distributed with Cygwin v1.0 such as bc.exe, dc.exe,
> etc all rely on canonical mode.  It is especially annoying to not be able
> to backspace over my mistakes with dc.exe -- I have to kill the program
> each time and start over.  Even if I were to modify the souce code to
> replace getc(stdin) with fgets(...), I still wouldn't be able to backspace...
> 
> And for that matter, you can't backspace with sh.exe, either.  I can't
> believe I'm the first person to notice this.
> 
> Hey Cygnus, are you reading this?  Is there any way we can fix canonical
> mode for v1.0?
> 

Uhm... you've got something not set correctly.  What is your TERM variable set
to?  It should read TERM=cygwin.  A paste of the output of `cygcheck -s -v -r'
would be helpful.


=====
Earnie Boyd < mailto:earnie_boyd@yahoo.com >
Cygwin Newbies, please visit
< http://www.freeyellow.com/members5/gw32/index.html >
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

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

Re: getc() problem with Cygwin v1.0

[Christopher Faylor]

On Thu, Jan 13, 2000 at 12:24:12PM -0500, Dtcohen@aol.com wrote:
>> If you need to wait until "RETURN" is pressed maybe you have succes with
>> "gets()". Using "scanf()" is dangerous, because sometimes "RETURN" is left in
>> the buffer.
>
>Yes, using gets() or fgets() for a small program would work better, but
>the real problem is that canonical mode is broken for v1.0 (the man
>page for "termio" explains this in detail, but it basically means getc(stdin)
>should block until a carriage return is entered).  Canonical mode also
>allows the user to backspace over his mistakes -- which also doesn't work
>with v1.0.

I just tried cat >/dev/null using the cygwin CD.  I could edit the line
as expected.  I tried this from the command line, under bash, and under
/bin/sh.  All of them worked fine.

I think that if canonical mode was really broken we would have heard about
it from a numbe of different directions by now.

I also tried your test case, which worked as expected.

As a wild guess, it sounds like you may not be using the Cygwin 1.0 DLL.

cgf

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

Re: getc() problem with Cygwin v1.0

[Dtcohen]

> Hallo Jim, 

Hallo Georg,

> 
> at first in ANSI-C there is no function getc( void ). There is 
> int getc( FILE *stream ) and int getchar( void ).

Yes, thank you for pointing that out (though I did have getc(stdin) correct
in my code).

> 
> The problem is a little bit more complicated. getchar() is reading one character
> from the input-stream and the function is not waiting for "RETURN". The question
> is: When is a keystroke put in in the stream "stdin"?
> 
> The following little program shows this:
> 
> #include <stdio.h>
> #include <string.h>
> 
> int main( void )
> {
>     char buffer[81];
>     int i, ch;
> 
>     int re = 0;
> 
>    /*----------------------------------------*/
> 
>     printf( "Enter a line: " );
> 
>     /* Read in single line from "stdin": */
>     for( i = 0; (i < 80) &&  ((ch = getc( stdin )) != EOF) 
>              && (ch != '\n'); i++ )
>     {
>         printf( "!ch = %c\n", ch );
>         buffer[i] = (char)ch;
>     }
> 
>         /* Terminate string with null character: */
>     buffer[i] = '\0';
>     printf( "%s\n", buffer );
> 
> 
>     printf( "READY, press Enter\n" );
>     getchar();
>     return re;
> }
> 
>     /*--------------------*/
> 
> 
> On my systems [ 1. Cygwin 20.1, 2. WindowsNT +  MinGw] the loop starts when the
> "Return" is pressed and prints then one character at one time.

Yes, your program demonstrates the problem nicely.  On Cygwin 20.1, I
get the following result:
Enter a line: This is a test.
!ch = T
!ch = h
!ch = i
!ch = s
!ch =  
!ch = i
!ch = s
!ch =  
!ch = a
!ch =  
!ch = t
!ch = e
!ch = s
!ch = t
!ch = .
This is a test.
READY, press Enter

On Cygwin v1.0, I get the following:
Enter a line: T!ch = T
h!ch = h
i!ch = i
s!ch = s
 !ch =  
i!ch = i
s!ch = s
 !ch =  
a!ch = a
 !ch =  
t!ch = t
e!ch = e
s!ch = s
t!ch = t
!ch = .

This is a test.
READY, press Enter

> 
> If you need to wait until "RETURN" is pressed maybe you have succes with
> "gets()". Using "scanf()" is dangerous, because sometimes "RETURN" is left in
> the buffer.

Yes, using gets() or fgets() for a small program would work better, but
the real problem is that canonical mode is broken for v1.0 (the man
page for "termio" explains this in detail, but it basically means getc(stdin)
should block until a carriage return is entered).  Canonical mode also
allows the user to backspace over his mistakes -- which also doesn't work
with v1.0.

Pre-compiled programs distributed with Cygwin v1.0 such as bc.exe, dc.exe,
etc all rely on canonical mode.  It is especially annoying to not be able
to backspace over my mistakes with dc.exe -- I have to kill the program
each time and start over.  Even if I were to modify the souce code to
replace getc(stdin) with fgets(...), I still wouldn't be able to backspace...

And for that matter, you can't backspace with sh.exe, either.  I can't
believe I'm the first person to notice this.

Hey Cygnus, are you reading this?  Is there any way we can fix canonical
mode for v1.0?

Jim Grishaw
dtcohen@aol.com

> 
> Dtcohen@aol.com wrote:
> > 
> > For Cygwin v1.0, getc() returns after every key is typed, instead
> > of waiting for the carriage return.  This is incorrect behavior.
> > With Cygwin B20.1 it correctly waits for the carriage return.
> > 
> > Does anyone know how this can be fixed?  Any pointers to the
> > source of the problem are also appreciated.
> > 
> > Many thanks,
> > Jim Grishaw
> > dtcohen@aol.com
> 

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

Re: getc() problem with Cygwin v1.0

[Georg Fusz]

Hallo Jim, 

at first in ANSI-C there is no function getc( void ). There is 
int getc( FILE *stream ) and int getchar( void ).

The problem is a little bit more complicated. getchar() is reading one character
from the input-stream and the function is not waiting for "RETURN". The question
is: When is a keystroke put in in the stream "stdin"?

The following little program shows this:

#include <stdio.h>
#include <string.h>

int main( void )
{
    char buffer[81];
    int i, ch;

    int re = 0;

   /*----------------------------------------*/

    printf( "Enter a line: " );

    /* Read in single line from "stdin": */
    for( i = 0; (i < 80) &&  ((ch = getc( stdin )) != EOF) 
             && (ch != '\n'); i++ )
    {
        printf( "!ch = %c\n", ch );
        buffer[i] = (char)ch;
    }

        /* Terminate string with null character: */
    buffer[i] = '\0';
    printf( "%s\n", buffer );


    printf( "READY, press Enter\n" );
    getchar();
    return re;
}

    /*--------------------*/


On my systems [ 1. Cygwin 20.1, 2. WindowsNT +  MinGw] the loop starts when the
"Return" is pressed and prints then one character at one time.

If you need to wait until "RETURN" is pressed maybe you have succes with
"gets()". Using "scanf()" is dangerous, because sometimes "RETURN" is left in
the buffer.

Dtcohen@aol.com wrote:
> 
> For Cygwin v1.0, getc() returns after every key is typed, instead
> of waiting for the carriage return.  This is incorrect behavior.
> With Cygwin B20.1 it correctly waits for the carriage return.
> 
> Does anyone know how this can be fixed?  Any pointers to the
> source of the problem are also appreciated.
> 
> Many thanks,
> Jim Grishaw
> dtcohen@aol.com

-- 
Georg Fusz

home-page: http://cadence.fb12.tu-berlin.de/~fusz/

Fon: 
Universitaet: +49 30 314 26 884
privat:     : +49 30 815 30 32
Handy:      : +49 173 20 10 696

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

getc() problem with Cygwin v1.0

[Dtcohen]

For Cygwin v1.0, getc() returns after every key is typed, instead
of waiting for the carriage return.  This is incorrect behavior.
With Cygwin B20.1 it correctly waits for the carriage return.

Does anyone know how this can be fixed?  Any pointers to the
source of the problem are also appreciated.

Many thanks,
Jim Grishaw
dtcohen@aol.com

See also my previous posting: "Blocking I/O with Cygwin v1.0", 1/4/00

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