On Wed, Jul 10, 2002 at 09:13:18PM -0700, bruno schwander wrote:
> I making a port (not much really) of Irit
> (http://www.cs.technion.ac.il/~irit/) a modelling environment.
>
> I am having some problems with terminal handling, so all termios guru out
> there, please help ! :-)
That's what I did for a terminal programm to setup the controlling tty:
void
settty(void) {
struct termios buf;
if (tcgetattr(STDIN_FILENO, &save_termios) < 0) {
printf("tcgetattr failed: %s\n", strerror(errno));
exit (1);
}
memcpy(&buf, &save_termios, sizeof(buf));
buf.c_lflag &= ~(ECHO | ICANON | IEXTEN | ISIG);
buf.c_iflag &= ~(ICRNL | INPCK | ISTRIP | IXON);
buf.c_cflag &= ~(CSIZE | PARENB);
buf.c_cflag |= CS8;
buf.c_oflag &= ~OPOST;
buf.c_cc[VMIN] = 1;
buf.c_cc[VTIME] = 0;
if (tcsetattr(STDIN_FILENO, TCSAFLUSH, &buf) < 0) {
printf("tcsetattr failed: %s\n", strerror(errno));
exit (1);
}
ttyset = 1;
return;
}
> At stratup, irit does the following
>
> Termio.c_cc[VEOF] = 0; /* MIN = 0, no minimal length to wait for. */
> Termio.c_cc[VEOL] = 1; /* TIME - 1 tenth of a second as time o
Setting VEOL or VEOF with disabled ICANON is senseless.
> which seems wrong, I think it should be
>
> Termio.c_cc[VMIN] = 0; /* MIN = 0, no minimal length to wait for. */
> Termio.c_cc[VTIME] = 1; /* TIME - 1 tenth of a second as time o
>
> then later:
>
> Termio.c_lflag &= ~ICANON;
Sparse initialisation may require specific defaults to work.
> basically, irit wants to manage line editing itself, to manage the irit
> command prompt. There is some code doing the ^A, ^H, etc handling and line
> printing, and reading periodically stdin.
>
> What I see happening, is that usually at the very beginning, input seems
> locked. Running in the debugger, I see that characters are fgetc'ed
> periodically, but fgetc always returns -1 even when there should be
> characters available.
>
> I then tried using fcntl(0, F_SETFL, O_NONBLOCK) instead of the above 2
> lines. which I thought would do the right thing, ie: non blocking IO, but
> anything available from stdin is buffered and provided on the next read.
> This works, however I am seeing something strange on stdout now: when
> outputting lots of lines, outputs stalls after a few dozen lines. Adding a
> usleep between each fwrite() solves the problem but slows it all
> down... (and is inherently wrong)
I'm not shure if nonblocking or character mode is compatible with
stdio.
I always used direct io in such cases.
> What is going on here ? I do not understand very well all the terminal/IO
> discipline here.
>
> I agree that this is all bad design, and should probably multithread or
> use select() but I am not Irit's author...
--
B.Walter COSMO-Project http://www.cosmo-project.de
[EMAIL PROTECTED] Usergroup [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
