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 <45334>; Mon, 16 Mar 1992 14:03:27 -0600
Received: from localhost by groucho.cs.psu.edu with SMTP id <2541>; Mon, 16 Mar 1992 15:02:46 -0500
To: rc@archone.tamu.edu
Subject: Re: Reactive Keyboard 
In-reply-to: Your message of "Mon, 16 Mar 92 07:03:43 EST."
             <9203161203.AA04226@piggy.ucsb.edu> 
Date: Mon, 16 Mar 1992 14:02:36 -0600
From: schwartz@groucho.cs.psu.edu
Message-Id: <92Mar16.150246est.2541@groucho.cs.psu.edu>


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