On Fri, 17 Jan 1997, Ground Zero Enterprises wrote:
> other adverse effects? I would like to be able to just use some
> commands, especially a visual editor like vi or pico or something from
> within the mud, but am not sure how to do so, or if it is even possible.
> Has anyone attempted this, with or without success, who could offer some
> insight into this subject.
>
Yeah, I've got it implemented on my mud. We've been testin it over a few
months to get some kinks worked out. Although you can use it to offer
access to a general shell, I only use it in conjunction with the secure
Pico editor (yeah the source from mud++ dev squad). Basically here are
the generalities...
start with yer normal mud process.
fork() process off, saving child pid on character descriptor_data struct
parent is main mud, continues on like nothing happened
child will be used further...
child prepares to send a SIG_CHLD to parent upon termination
(sigaction and the like)
child forks once again
one half for the execl() branch (where spico is actually called from)
the other half for the route_io() function which acts as a traffic
cop between the execl() branch and the main mud
grabs a couple available ptys (pseudo terminals)
sets up communication between player descriptor and new pseudo terminal
then close stdin/out/err on execl branch, dup() the new channel into
those three descriptors (0,1,2)
now call execl() (actual spico call)
all input from remote site gets routed thru main mud (original parent)
to the execl() branch via the pty and route_io() set up earlier
upon exit of the editor, the child dies, sending a SIG_CHLD to parent
the parent receives this signal via a signal handler aptly called
grim_reaper()
using a wait3() call to determine status of the dead child (interesting
eh? :P) we receive the pid of the dead child...
the reaper then scans thru the descriptor list, locates the one
with the matching pid, and returns that descriptor (and normally char)
into the world of the main mud...
advantages? - remote access to stuff like pico, vi or even a shell
i use spico cause it doesnt allow directory traversal
so it restricts them to a certain directory...
just like using pico on yer local terminal..
it's just kewl and can be (actually is) integrated
into OLC for use with help files or room descrips
or whatever (sorry, no oasis or obuild, i have it
integrated with my olc, RoAOLC)
disadvantages? - oh you got some memory usage there, whever you fork()
a large process over, it basically creates two of those
processes, gulp
if you use anything other than spico or some other
secure entity, you run the risk of a security issue
but you can limit via the mud code like you would any
other mud command to lower levels, so security isn't
really an implementation detail within this scope
not an easy thing to understand, let alone trying to
slap it into a mud... but
if you guys feel interested i did get it to compile on 3.0bpl11, though
i never fired it up and tried to use it on 3.0 ( i run off a combo of
circle2.2, diku old style, some lp stuff, and RoA )
though it definitely will NOT be a patch addition, i can slap together
a couple files and some general rules to integrate if it's a big deal
with people now :) (For those who remember, I mentioned this same
chunk of code about 3 months ago, only a couple people were interested
at the time.)
btw, for those who were payin close attention, yeah i did fork twice
so yer thinkin there may be 3 copies floatin around... but the second fork
is a vfork() and is more efficient than regular fork() so it doesnt count
:P
+-----------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://cspo.queensu.ca/~fletcher/Circle/list_faq.html |
+-----------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/18/00 PST