Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: auspex!guy@uunet.uu.net (Guy Harris)
Newsgroups: comp.sys.sun
Subject: Re: Filename completion in shelltools and cmdtools
Keywords: Windows
Message-ID: <1510@brchh104.bnr.ca>
Date: 27 Jan 91 01:20:24 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 29
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v10n17
X-Sun-Spots-Digest: Volume 10, Issue 37, message 1
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

>This is a bug for cmdtool under both SunView and OpenWin. A simple trick
>to get around it is to run "rsh hostname" from that window.

Yup, that basically just permanently shoves the "cmdtool" into
"uncooked/no echo" mode, so that it merely passes keystrokes through to
the tty driver, rather than taking over the canonicalization functions of
the tty driver and interpreting keystrokes itself.

The problem with C shell filename completion is that, in order to do
filename completion in cooked mode, it performs some rather unnatural acts
with the tty driver, and

1) the pseudo-tty driver can't notify the "cmdtool" code about "ioctl"s on
   the slave side in a fashion sufficiently pleasant to make that work
   ("fixed in S5R4")

and

2) even if it could, the "cmdtool" code's ideas of what it should to in
   order to take over the tty driver's canonicalization functions don't
   include coping with a program doing Weird Stuff like a bunch of TIOCSTI's
   in no-echo mode followed by some more TIOCSTI's in echo mode.

I've noticed several complaints that this doesn't even work in *shelltool*
in Open Windows; I haven't been able to reproduce that myself under OW,
and in one case the person later said "it really only happens in cmdtool".
Do the "shelltool"s in which this happens have scrollbars?  If so, even if
they were started by typing "shelltool" and even if they say "shelltool",
they're probably really "cmdtool"s.