Path: utzoo!attcan!uunet!nih-csl!lhc!ncifcrf!haven!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!rutgers!cbmvax!ag
From: ag@cbmvax.commodore.com (Keith Gabryelski)
Newsgroups: comp.unix.questions
Subject: Re: BSD vs. SVR4 typehead flush after tty mode change
Message-ID: <15175@cbmvax.commodore.com>
Date: 16 Oct 90 05:30:49 GMT
References: <15042@cbmvax.commodore.com> <4187@auspex.auspex.com> <14148@smoke.BRL.MIL> <4191@auspex.auspex.com>
Reply-To: ag@cbmvax.commodore.com (Keith Gabryelski)
Organization: Commodore-Amiga Unix; West Chester, PA
Lines: 37

In article <4191@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>It sems to me that a bug was introduced in the kernel solely in order
>>to avoid fixing the C shell, which is clearly screwed up in its input
>>handling.  In interactive command-line editing mode, a shell should
>>read() only 1 character at a time.
>
>I won't defend the unnatural acts the C shell engages in to implement
>"filec",
>
>BUT
>
>that's not *the* problem with switching modes, it's just the most
>*obvious* one.
>
>Consider a more vanilla shell, one that runs in cooked mode.  You type
>some characters while exiting some program that runs in uncooked mode,
>those characters being typed while still in uncooked mode.  As such,
>they probably went upstream immediately and are sitting at the stream
>head.

If I am not mistaken I remember noting this same problem with
switching from non-canonized processing to canonized processing under
the old (non streams) tty subsystem.  Ie, this is not a new problem.

It also seems to me that flushing the stream when ICANON is turned
on may fix this problem for csh, but breaks typeahead (for programs
that go in an out of ICANON) and breaks termio (flushing on TCSETS).

Try (while in vi).

	:!sleep 10
	:!echo foo
	:!echo bar
	:!echo baz


Pax, Keith