From: austin@cs.wisc.edu (Todd Austin)
Subject: Re: A VI editor written in LPC??
Keywords: editor
Organization: U of Wisconsin CS Dept
Date: Fri, 8 Jan 1993 14:34:55 GMT

In article <C0JCtI.Iwx@unccsun.uncc.edu>, bkyoung@unccsun.uncc.edu (Brian K Young) writes:
|> Has anyone ever seen (or better yet, written or have access to) an      
|> any editor for an LPMud other than the standard mud editor? I've
|> heard about several folks attempting to write VI editors in LPC,
|> but never heard how their attempt turned out. While the standard

I think it would be a nearly insurmountable task to code a full screen
editor in LPC.  The dynamic nature of storage in such an editor would be
very clumsy to code with dynamic arrays, and you would have to implement
a somewhat functioning termcap package.  Not an easy task...

I've used three methods to get full screen edit support on muds (I've never used ed!)

1) run the mud on your workstation ;)

2) edit locally with your favorite editor and then ftp the files back and
forth to the mud with 'ftp'.  Your mud host will have to run a ftp deamon
hacked to support the mud passwords and file structure.  There are a number
of these floating around.  If you want a copy of the one I hacked, mail me.
It supports 2.4.5 muds, MudOS, and UnderDark.  Of course this method is useless
if you don't have an account at the site from which you telnet (e.g. if you are
using public access telnet).

3) a while back I hacked the MudOS driver to support vi (elvis really)
from any connected interactive.  Its a little tricky to do, the technique I used
fork'ed an editor processor in the driver, and then "lent" the socket to the
editor process.  I'll list the changes that need to be made:

	- create an editor efun, like full_ed("file_name")
		- when the efun is called, call a master_ob lfun, e.g.,
		  valid_edit(fname) which ensures the filename is accessable
		  by the player
		- fork an editor process, note, you can't just use "vi" here as
		  it has shell escape capabilities.  I used "elvis" and hacked the
		  source such that the shell access was removed
		- massage the player socket back to its original state, this includes
		  re-enabling non-blocking I/O and setting the telnet line state to
		  character mode
		- the player is now connected to the program, but the mud now has to
		  be taught to ignore the socket for a while, so just add a state bit to
		  the interactive structure that "masks out" the select bits in the
		  subsequent calls to select() (this is trivial in the MudOS driver)
		- any subsquent mud output to the player in an editor will just be
		  spooled into the driver's socket buffer, also, the output is stifled
		  while in the editor
		- enable a handler to catch SIGCHLD from the editor when it terminates
		- end of efun()

	- when the editor quits, you will get a SIGCHLD (possibly many), so
		  now do wait3()'s on all the fork'ed interactives to see who has
		  terminated (possibly many); the wait3() is also required to take the
		  process out of the <defunct> state; also note, don't muck with mud
		  variable from a signal handler (if you don't know why, take an OS
		  course or avoid this project ;)
		- set the interactive state back to "in game"
		- again massage the socket to be non-blocking and set the telnet line
		  state to "line"
		- check for pending output in the internal socket buffer and, if any,
		  dump it out to the player

Terminal handling is relatively simple if you mud provides environment variables.  Just
have the mud users set their "TERM" variable to their terminal type, and pass these
variables to the subprocess through the "envp" parameter of the exec() call (this is
just what a normal unix shell does).

Actually, you can extend this notion more, so that any program can be run; just
pass in both the program name and the arguments to a master_ob function that
evaluates if the execution would be safe.  Using this it would be possible to
make any full screen program available to any player.  For example, I made a
tetris room, where players could play the game in a subprocess.  Another useful
application could grant shell access to high level admins, say, through an admin
terminal.  This could be a security risk, if you make a coding error, but ultimately,
all security of this powerful efun can be controlled from the master_ob.

Klaas(Todd)
Newsgroups: rec.games.mud.lp