Re: Reactive Keyboard

Re: Reactive Keyboard

[Josh N. Pritikin]

> perhaps fd passing?  fd#10 (<--some well-known number) would be a pipe
> to/from the editor where you could write() changes in cwd?  (fd 3 is
> used by Dan Bernstein's pty package, for /dev/tty, btw.)

Yah. I was going to suggest a similar mechanism.

> we're sort of going off the subject of rc here, but hopefully, enough
> of us are concerned about making *modular* (not in the shell) line
> editing interfaces that we can have some talk about it.  besides, rc
> is perfect, already, right??  :-)

That's why I brought it up. rc is pretty much exacly what I want in a
shell (except for its lack of job control :-) but I would never
consider using it without emacs like editing functions. I feel that
something like rk provides this without bloating rc with unnecessary
features. From this point of view, rk and similar hacks seems quite
relivent to this list.

Currently, I don't know enough about the tty to try hacking rc-rk
communication in but it sounds like an interesting project if I have
time.

( Josh Pritikin jpab+@andrew.cmu.edu
( It might be hot in Pittsburgh, but at least it's humid.

Re: Reactive Keyboard

[schwartz]

| ... i fixed by hacking the completion code to get pwd every time.  :(
| 
| the only drawbacks here are, if you are working in another command
| processor (ftp, a line editor, ???) ...

Exactly.  A solution that isn't robust isn't very statisfying to me.
(Fep "front end processor" is an ile like thing that was posted to the
net long ago.)

| perhaps fd passing?  ...

Yes, fd passing might be useful.  

| ... except on suns that have a world-writable utmp... 

Not on _my_ Sun! :-)   This is an exercise in tidying things up, after
all.

| (then we
| still have problems with pty ownership etc.).  i can't conceive of a
| flexible editor that *could* run as root.  perhaps one that setuid()s
| away from it right after making pty/utmp changes; but how to change
| the pty back when the process dies?

Yes, some tools, like screen, do that.  You just have to make sure they
don't die unexpectedly.  Dan's pty does that job in addition to making
sure all the system files are maintained, and taking care to run the
shell with the right uid.

Reactive Keyboard

[Josh N. Pritikin]

I'm new to this mailing list but I'm going to take a risk and post
this anyway.

I recently found a program called Reactive Keyboard. Here's a
description taken from the man page:

     The Reactive Keyboard is a general-purpose command-line editor with the
     addition of predictive text generation.  It interfaces with a standard
     shell and allows simple editing of input lines.  It will also predict
     new input lines based on previous input.

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...

( Josh Pritikin jpab+@andrew.cmu.edu
( It might be hot in Pittsburgh, but at least it's humid.

Re: Reactive Keyboard

[schwartz]

| 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? :-)