Re: read bug in Cygwin xterm window only
On Sat, Jun 11, 2005 at 05:00:54PM +0200, Jason Curl wrote: >Just downloaded Cygwin 15.17 (without anything else), and the problem is >now fixed. Noted that the release notes contained the entry > >cgf: Fix problem with tty reads where vmin == vtime == 0. > >that probably did it. So, the moral of the story is: Try the latest version of a program before reporting problems with an old version of a program -- especially when replying to two month old email messages about a program. cgf
Re: read bug in Cygwin xterm window only
Jason Curl wrote: Christopher Faylor wrote: On Wed, Jun 08, 2005 at 09:22:08PM +0200, Jason Curl wrote: On Fri, Apr 29, 2005 at 05:54:35PM -0700, Peter Farley wrote: The following program demonstrates what looks to me like a bug in the "read" function in an xterm (as opposed to a Cygwin console window). To run the test, compile with: gcc -g -o xtermbug.exe xtermbug.c When you run it in a console window, you can enter normal keyboard characters, then a return to see "cmdline=". Press the Esc key to exit the program. Unfortunately I'm seeing exactly the same problem too, and have so for some time. I've also noticed that a read() giving a particular length will ignore the length field and actually read more data in some cases. Peter provided a test case which I used to diagnose a problem with Cygwin. I fixed the problem and released a new version of cygwin which fixed the problem so it is unlikely that this is exactly the same problem. Please provide a simple test case which shows your specific problem. And, also please provide the details mentioned at http://cygwin.com/problems.html . Sure - I'll start a new post for this as you mention it may be different. By the way, what version was it fixed in? I just confirmed that I'm using cygwin 15-11 (rather old then I think) and the problem exists. I'm upgrading to 15-16 now, and will later test it with 15-17 when I have a better internet connection. Just downloaded Cygwin 15.17 (without anything else), and the problem is now fixed. Noted that the release notes contained the entry cgf: Fix problem with tty reads where vmin == vtime == 0. that probably did it. Thanks!
Re: read bug in Cygwin xterm window only
Christopher Faylor wrote: On Wed, Jun 08, 2005 at 09:22:08PM +0200, Jason Curl wrote: On Fri, Apr 29, 2005 at 05:54:35PM -0700, Peter Farley wrote: The following program demonstrates what looks to me like a bug in the "read" function in an xterm (as opposed to a Cygwin console window). To run the test, compile with: gcc -g -o xtermbug.exe xtermbug.c When you run it in a console window, you can enter normal keyboard characters, then a return to see "cmdline=". Press the Esc key to exit the program. Unfortunately I'm seeing exactly the same problem too, and have so for some time. I've also noticed that a read() giving a particular length will ignore the length field and actually read more data in some cases. Peter provided a test case which I used to diagnose a problem with Cygwin. I fixed the problem and released a new version of cygwin which fixed the problem so it is unlikely that this is exactly the same problem. Please provide a simple test case which shows your specific problem. And, also please provide the details mentioned at http://cygwin.com/problems.html . Sure - I'll start a new post for this as you mention it may be different. By the way, what version was it fixed in? I just confirmed that I'm using cygwin 15-11 (rather old then I think) and the problem exists. I'm upgrading to 15-16 now, and will later test it with 15-17 when I have a better internet connection. cgf
Re: read bug in Cygwin xterm window only
On Wed, Jun 08, 2005 at 09:22:08PM +0200, Jason Curl wrote: >On Fri, Apr 29, 2005 at 05:54:35PM -0700, Peter Farley wrote: >>The following program demonstrates what looks to me >>like a bug in the "read" function in an xterm (as >>opposed to a Cygwin console window). To run the test, >>compile with: >> >>gcc -g -o xtermbug.exe xtermbug.c >> >>When you run it in a console window, you can enter >>normal keyboard characters, then a return to see >>"cmdline=". Press the Esc key to exit >>the program. > >Unfortunately I'm seeing exactly the same problem too, and have so for >some time. I've also noticed that a read() giving a particular length >will ignore the length field and actually read more data in some cases. Peter provided a test case which I used to diagnose a problem with Cygwin. I fixed the problem and released a new version of cygwin which fixed the problem so it is unlikely that this is exactly the same problem. Please provide a simple test case which shows your specific problem. And, also please provide the details mentioned at http://cygwin.com/problems.html . cgf
Re: read bug in Cygwin xterm window only
Peter Farley wrote: Hi all, The following program demonstrates what looks to me like a bug in the "read" function in an xterm (as opposed to a Cygwin console window). To run the test, compile with: gcc -g -o xtermbug.exe xtermbug.c When you run it in a console window, you can enter normal keyboard characters, then a return to see "cmdline=". Press the Esc key to exit the program. Unfortunately I'm seeing exactly the same problem too, and have so for some time. I've also noticed that a read() giving a particular length will ignore the length field and actually read more data in some cases. I haven't seen these problems under a normal console, nor under xterm on other operating systems (e.g. Linux). When run in an xterm window, the first keypress causes this behavior: 1. Select returns with rc = 0 and readset set to indicate that a key was received 2. "read" returns with kblen = 1 and kbbuf[0] = '\0' 3. (1) and (2) repeat forever. I put in a "maxdbg" parameter and terminate the program after 5 occurrences of this loop. This problem was first detected trying to run a copy of the hercules IBM mainframe emulator in a Cygwin xterm window. The code below is extracted and minimalized as much as possible from the hercules keyboard input routine. Peter Farley
read bug in Cygwin xterm window only
Hi all,
The following program demonstrates what looks to me
like a bug in the "read" function in an xterm (as
opposed to a Cygwin console window). To run the test,
compile with:
gcc -g -o xtermbug.exe xtermbug.c
When you run it in a console window, you can enter
normal keyboard characters, then a return to see
"cmdline=". Press the Esc key to exit
the program.
When run in an xterm window, the first keypress causes
this behavior:
1. Select returns with rc = 0 and readset set to
indicate that a key was received
2. "read" returns with kblen = 1 and kbbuf[0] = '\0'
3. (1) and (2) repeat forever.
I put in a "maxdbg" parameter and terminate the
program after 5 occurrences of this loop.
This problem was first detected trying to run a copy
of the hercules IBM mainframe emulator in a Cygwin
xterm window. The code below is extracted and
minimalized as much as possible from the hercules
keyboard input routine.
Peter Farley
xtermbug.c:
/*---*/
/* This is a test program to show a cygwin xterm bug,
possibly */
/* in the read function.
*/
/*---*/
/*---*/
/* Definitions for keyboard input sequences
*/
/*---*/
#define KBD_DELETE "\x1B[3~"
#include
#include
#include
#include
#include
#include
#define MSG_SIZE80 /* Size of one
message */
#define CMD_SIZE 32767 /* Length of
command line*/
#define BYTE unsigned char
int ttyreset = 0;
struct termios kbattr; /* Terminal I/O
structure*/
/*---*/
/* xterm display subroutine
*/
/*---*/
void xterm_display (void)
{
int rc; /* Return code
*/
int i; /* Array
subscripts */
charcmdline[CMD_SIZE+1];/* Command
line buffer */
int cmdoff = 0; /* Cursor
position in cmdline*/
int cmdlen = 0; /* Number of
bytes in cmdline*/
//BYTEc; /* Character
work area */
FILE *confp; /* Console
file pointer */
size_t kbbufsize = CMD_SIZE; /* Size of
keyboard buffer */
char *kbbuf = NULL; /* Keyboard
input buffer */
int kblen; /* Number of
chars in kbbuf */
int keybfd; /* Keyboard
file descriptor */
int maxfd; /* Highest
file descriptor */
fd_set readset;/* Select file
descriptors */
struct timeval tv; /* Select
timeout structure */
int maxdbg = 0;
/* Set up the input file descriptors */
confp = stdout;
keybfd = STDIN_FILENO;
fprintf(confp, "start kbbuf=%8.8X,&kbbuf=%8.8X\n",
kbbuf, &kbbuf);
/* Obtain storage for the keyboard buffer */
if (!(kbbuf = (char *)malloc (kbbufsize)))
{
fprintf(stderr, "HHCPN002S Cannot obtain
keyboard buffer: %s\n",
strerror(errno));
return;
}
fprintf(confp, "start
kbbuf=%8.8X,&kbbuf=%8.8X,*kbbuf=%8.8X\n",
kbbuf, &kbbuf, *kbbuf);
/* Set screen output stream to fully buffered */
setvbuf (confp, NULL, _IOFBF, 0);
/* Put the terminal into cbreak mode */
tcgetattr (keybfd, &kbattr);
kbattr.c_lflag &= ~(ECHO | ICANON);
kbattr.c_cc[VMIN] = 0;
kbattr.c_cc[VTIME] = 0;
tcsetattr (keybfd, TCSANOW, &kbattr);
ttyreset = 1;
fprintf(confp, "Starting while(1) loop.\n");
fflush(confp);
/* Process messages and commands */
while (1)
{
/* Set the file descriptors for select */
FD_ZERO (&readset);
FD_SET (keybfd, &readset);
maxfd = keybfd;
/* Wait for a key to be pressed,
or the inactivity interval to expire */
tv.tv_sec = 1;
tv.tv_usec = 1 % 100;
rc = select (maxfd + 1, &readset, NULL, NULL,
&tv);
if (rc < 0 )
{
if (errno == EINTR) continue;
fprintf (stderr,
"HHCPN004E select: %s\n",
strerror(errno));
break;
}
fprintf(confp, "rc=%d,readset={%8.8X,%8.8X}\n", rc,
readset.fds_bits[0], readset.fds_bits[1]);
fflush(confp);
/* If keyboard input has arrived then process
it */
if (FD_ISSET(keybfd, &readset))
{
/* Read character(s) from the keyboard */
kblen = read (keybfd, kbbuf, kbbufsize-1);
