Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!amdahl!pyramid!prls!mips!dce
From: dce@mips.COM (David Elliott)
Newsgroups: comp.unix.questions
Subject: Re: Is typeahead loss a generic ksh problem?
Message-ID: <2208@quacky.mips.COM>
Date: 18 May 88 15:13:24 GMT
References: <8062@elsie.UUCP>
Reply-To: dce@mips.COM (David Elliott)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 34

(I apologize if this is a repost.  I looked, and it doesn't appear to
 have gone out, but flakiness is flakiness.)

In article <8062@elsie.UUCP> ado@elsie.UUCP (Arthur David Olson) writes:
>We're using the 02/21/85b version of ksh on a VAX 11/750 running MORE/bsd 4.3.
>At times ksh will flush typeahead, as shown by the transcript below:

Typeahead flush is a problem with most line-editors, which is one of
the reasons it is preferable to implement line-editors in the tty
instead of in the shells.  When you change from standard (cooked) mode
to raw or pseudo-raw mode, you lose the data.

A similar problem exists with the Livermore csh line-editor and is likely
to exist in tcsh.  It does not exist in the old BSD command completion
interface, which uses alternate break characters and TIOCSTI.

What can happen is that either typeahead gets flushed, or it gets
eaten by the editor.  For example, if you type the lines

	sleep 20
	head -1
	echo foo
	echo bar

wait for the prompt, and then type "ls", you might expect the "head -1"
to read and print "echo foo", the word "bar" to be printed, and an "ls"
to be executed.  Instead, the "head -1" will read "ls", and "foo" and
"bar" will be printed.  In other words, the line-editor has eaten
everything in the queue, even though it does not use the data.

You learn to live without typeahead or without a line editor.  I chose
to live without the editor.

-- 
David Elliott		dce@mips.com  or  {ames,prls,pyramid,decwrl}!mips!dce