LPC shell?

[quixadhal]

Ok, Happy New Year folks.

Instead of being asleep and drunk, as I should be... I find myself awake and thinking about an old idea I tossed around a few years ago... the inside-out MUD server.

The short version is this... most MUD servers spend a LOT of their time and code trying to mimic systems that are already well established and in place, at least on the unix platform.  The login/account system, the shell environment and all the user input processing and command execution that entails, the terminal handling system... instead of making the mud server do all that, why not let the OS do it, the way it already does for regular logins?

IE:  Why not write a custom shell which talks to the MUD server directly, and replaces /bin/bash (or whatever)?

The benefits have already been discussed elsewhere, and I think the security issues are manageable.  The question is, does anyone have a good idea of what would work well for such a thing?

I considered modifying bash, but anyone who's looked at GNU code knows what a nightmare that would be.  I also considered using perl/python/etc to write a shell myself, and that's certainly an option... but then there's PIKE.

Does anyone actually use PIKE?  It would be a bonus if you had a login shell that could understand LPC right there as your scripting language, but not essential.

Currently, iPython seems like a good place to start, but I'm open to suggestions.

To be clear, the concept is to have a login shell that works properly with full terminal support -- just like bash -- but also connects to your MUD server to handle events.  So when the orc walks into the room, you want the game server to push that event to your shell, and have it do the display and redraw your prompts/etc as needed.  When you type 'kill orc', it should execute a "kill" command which would ultimately send the kill command to the server and print the results.

If such a concept worked, you'd essentially decouple the display system and much of the user-input parsing from the game server and move them into the individual login shells... giving you better performance (multi-threading) and much cleaner server code.

Please discuss.

[Shem (aka MadScientist)]

I read this; and I like the idea for originality alone; however ... I'm having trouble wrapping my mind around it. 
 
Were you envisioning this as a default connection layer/type for ALL MUD logins, or just a superset for Wizard/Builder/etc super characters?  Would the extended command set (i.e. Kill) essentially become system level commands that just interacted with MUD object?
 
I'm going to let this one simmer for awhile I guess.

[quixadhal]

The way I was picturing such a system is to have (basically) a custom shell which acts like (and might even be modified from) a standard system login shell (bash, tcsh, etc), but which also opens a socket to the game server to allow communication of events.

When you type "look", you'd be running some command binary which would send a "look" command packet to the server, and emit the results in a formatted way to the shell.  The command could be a C program, a perl script, whatever... the important point is that it sends structured data to the game server and gets structured data back (or perhaps causes the game server to send the data over the shell's socket).

This would allow builders to directly access files with whatever editor they prefer, and would give ordinary users the same kinds of alias/macro abilities you'd expect from a shell.  More importantly, since you have termcap/termlib support, you can use any full screen applications, both in-game and external... you just have to form a clean API for commands that affect game state.

[Nulvect]

I would *kill* to be able to use my standard vim setup for mud coding...

[Sluggy]

Just to answer your question about pike: I have used it and as much as I hate to say this, my recommendation would be to stay very far away from it. I love LPC and love the idea of pike but - it's still in its formative stages, it isn't being developed much these days, and there is very little documentation, support libraries, and general user knowledge. Quite frankly it's just sort of a pain to use with little payoff.

Also, I'd like to crush this idea that Pike and LPC are interchangeable words. They are not. Suggesting that Pike and LPC are the same is kinda like suggesting that C and C++ are the same. 

[Shem (aka MadScientist)]

I'm going to do some research on the technical feasability and pro/con's of this idea.
 
Thanks for floating this idea out there.

[Nulvect]

I have long dreamed of a way to make a kind of whitelist of system commands that the driver would pass through to a shell. It makes no sense to rewrite cd, ls, rm, mv, etc in lpc when there are perfectly good commands already written that will run faster, have more features, and have had way more eyes debugging them. I realize there is an "external command" module in some drivers, but I've never actually found documentation on it...

[quixadhal]

Passing commands through the driver is a huge security risk, because the commands run with the driver's userid and permissions.  So any exploit can affect any part of the game.

My idea is to give every player a shell account, but instead of a regular login shell, they get a mud client which directly connects to the game server, but which executes commands just like a login shell.  So the player "bob" might have shell commands for look/kill/get/logout, which basically just talk to the game server and return data to the shell for display.  A builder "ted" might have access to commands like dig/link/clone/dest, as well as file editors and such.  Because "ted" is a user account, the regular unix filesystem handles what files they're allowed to edit.

For this to work ideally, you need a filesystem that support ACL lists (which most modern ones do).  You could do it via groups, but you'd need to be super-careful about setuid/setgid stuff.