From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from groucho.cs.psu.edu ([130.203.2.10]) by archone.tamu.edu with SMTP id <45340>; Sun, 15 Mar 1992 23:00:32 -0600 Received: from localhost by groucho.cs.psu.edu with SMTP id <2541>; Sun, 15 Mar 1992 23:59:56 -0500 To: "Josh N. Pritikin" cc: rc@archone.tamu.edu Subject: Re: Reactive Keyboard In-reply-to: Your message of "Sun, 15 Mar 92 20:14:50 EST." Date: Sun, 15 Mar 1992 22:59:46 -0600 From: schwartz@groucho.cs.psu.edu Message-Id: <92Mar15.235956est.2541@groucho.cs.psu.edu> | If you want to get a copy, I believe its on export.lcs.mit.edu. My | thought is that rk could replace readline and history as an interactive | interface to rc... Rk is a lot of fun. If your terminal can do underlining, be sure to turn that on in the rksetup; it looks much better. (If you aren't using a VAX, you'll need to fix a bug in rksetup where it assumes that NULL == "" for some of the termcap strings.) One problem, however, with rk and related tools (atty, fep, etc) is that they do completion incorrectly. They can (and do) try and track the current directory, but even in principle that is wrong, since the shell might be executing on a different machine than the input editor. I've been thinking about clean ways to allow the shell to do completion and communicate with the editor; it seems like that would be the best overall scheme. One other problem with these and other pty related items is that they all do pty handling in idiosyncratic ways. Even worse, unless they can run as root, they cannot change pty modes and ownership nor make entries in e.g. /etc/utmp. (Rk suffers that flaw.) The best fix for that stuff is to rip out all the custom pty code, and drop in a nice modular replacement, like Dan Bernstein's pty program. It isn't perfect, but its a good start. | ( It might be hot in Pittsburgh, but at least it's humid. Almost as nice as Philly, hey? :-)