tmi2_fluffos_v2/
tmi2_fluffos_v2/bin/
tmi2_fluffos_v2/etc/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/ChangeLog.old/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/Win32/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/compat/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/compat/simuls/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/include/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/clone/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/command/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/data/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/etc/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/include/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/inherit/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/inherit/master/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/log/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/single/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/single/tests/compiler/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/single/tests/efuns/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/single/tests/operators/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/testsuite/u/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/tmp/
tmi2_fluffos_v2/fluffos-2.7-ds2.018/windows/
tmi2_fluffos_v2/lib/
tmi2_fluffos_v2/lib/adm/
tmi2_fluffos_v2/lib/adm/daemons/languages/
tmi2_fluffos_v2/lib/adm/daemons/network/I3/
tmi2_fluffos_v2/lib/adm/daemons/virtual/
tmi2_fluffos_v2/lib/adm/daemons/virtual/template/
tmi2_fluffos_v2/lib/adm/news/
tmi2_fluffos_v2/lib/adm/obj/
tmi2_fluffos_v2/lib/adm/obj/master/
tmi2_fluffos_v2/lib/adm/priv/
tmi2_fluffos_v2/lib/adm/shell/
tmi2_fluffos_v2/lib/adm/tmp/
tmi2_fluffos_v2/lib/cmds/
tmi2_fluffos_v2/lib/d/
tmi2_fluffos_v2/lib/d/Conf/
tmi2_fluffos_v2/lib/d/Conf/adm/
tmi2_fluffos_v2/lib/d/Conf/boards/
tmi2_fluffos_v2/lib/d/Conf/cmds/
tmi2_fluffos_v2/lib/d/Conf/data/
tmi2_fluffos_v2/lib/d/Conf/logs/
tmi2_fluffos_v2/lib/d/Conf/obj/
tmi2_fluffos_v2/lib/d/Conf/text/help/
tmi2_fluffos_v2/lib/d/Fooland/adm/
tmi2_fluffos_v2/lib/d/Fooland/data/
tmi2_fluffos_v2/lib/d/Fooland/data/attic/
tmi2_fluffos_v2/lib/d/Fooland/items/
tmi2_fluffos_v2/lib/d/TMI/
tmi2_fluffos_v2/lib/d/TMI/adm/
tmi2_fluffos_v2/lib/d/TMI/boards/
tmi2_fluffos_v2/lib/d/TMI/data/
tmi2_fluffos_v2/lib/d/TMI/rooms/
tmi2_fluffos_v2/lib/d/grid/
tmi2_fluffos_v2/lib/d/grid/adm/
tmi2_fluffos_v2/lib/d/grid/data/
tmi2_fluffos_v2/lib/d/std/
tmi2_fluffos_v2/lib/d/std/adm/
tmi2_fluffos_v2/lib/data/adm/
tmi2_fluffos_v2/lib/data/adm/daemons/
tmi2_fluffos_v2/lib/data/adm/daemons/doc_d/
tmi2_fluffos_v2/lib/data/adm/daemons/emoted/
tmi2_fluffos_v2/lib/data/adm/daemons/network/http/
tmi2_fluffos_v2/lib/data/adm/daemons/network/services/mail_q/
tmi2_fluffos_v2/lib/data/adm/daemons/network/smtp/
tmi2_fluffos_v2/lib/data/adm/daemons/news/archives/
tmi2_fluffos_v2/lib/data/attic/connection/
tmi2_fluffos_v2/lib/data/attic/user/
tmi2_fluffos_v2/lib/data/std/connection/b/
tmi2_fluffos_v2/lib/data/std/connection/l/
tmi2_fluffos_v2/lib/data/std/user/a/
tmi2_fluffos_v2/lib/data/std/user/b/
tmi2_fluffos_v2/lib/data/std/user/d/
tmi2_fluffos_v2/lib/data/std/user/f/
tmi2_fluffos_v2/lib/data/std/user/l/
tmi2_fluffos_v2/lib/data/std/user/x/
tmi2_fluffos_v2/lib/data/u/d/dm/working/doc_d/
tmi2_fluffos_v2/lib/data/u/l/leto/doc_d/
tmi2_fluffos_v2/lib/data/u/l/leto/smtp/
tmi2_fluffos_v2/lib/doc/
tmi2_fluffos_v2/lib/doc/driverdoc/applies/
tmi2_fluffos_v2/lib/doc/driverdoc/applies/interactive/
tmi2_fluffos_v2/lib/doc/driverdoc/concepts/
tmi2_fluffos_v2/lib/doc/driverdoc/driver/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/arrays/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/buffers/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/compile/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/ed/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/filesystem/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/floats/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/functions/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/general/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/mappings/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/numbers/
tmi2_fluffos_v2/lib/doc/driverdoc/efuns/parsing/
tmi2_fluffos_v2/lib/doc/driverdoc/lpc/constructs/
tmi2_fluffos_v2/lib/doc/driverdoc/lpc/preprocessor/
tmi2_fluffos_v2/lib/doc/driverdoc/lpc/types/
tmi2_fluffos_v2/lib/doc/driverdoc/platforms/
tmi2_fluffos_v2/lib/doc/mudlib/
tmi2_fluffos_v2/lib/ftp/
tmi2_fluffos_v2/lib/include/driver/
tmi2_fluffos_v2/lib/log/
tmi2_fluffos_v2/lib/log/driver/
tmi2_fluffos_v2/lib/obj/net/
tmi2_fluffos_v2/lib/obj/shells/
tmi2_fluffos_v2/lib/obj/tools/
tmi2_fluffos_v2/lib/std/adt/
tmi2_fluffos_v2/lib/std/board/
tmi2_fluffos_v2/lib/std/body/
tmi2_fluffos_v2/lib/std/fun/
tmi2_fluffos_v2/lib/std/living/
tmi2_fluffos_v2/lib/std/object/
tmi2_fluffos_v2/lib/std/shop/
tmi2_fluffos_v2/lib/std/socket/
tmi2_fluffos_v2/lib/std/user/
tmi2_fluffos_v2/lib/std/virtual/
tmi2_fluffos_v2/lib/student/
tmi2_fluffos_v2/lib/student/kalypso/
tmi2_fluffos_v2/lib/student/kalypso/armor/
tmi2_fluffos_v2/lib/student/kalypso/rooms/
tmi2_fluffos_v2/lib/student/kalypso/weapons/
tmi2_fluffos_v2/lib/u/l/leto/
tmi2_fluffos_v2/lib/u/l/leto/cmds/
tmi2_fluffos_v2/lib/www/errors/
tmi2_fluffos_v2/lib/www/gateways/
tmi2_fluffos_v2/lib/www/images/
tmi2_fluffos_v2/old/
tmi2_fluffos_v2/win32/
 
		Watcher's Shadow Shell System (SHSH)
		====================================
 
		File	:   /obj/shells/shsh.c
		Version	:   4.5  (Completed : 04/14/1993)
 
		Creator	:   Glenn Ferguson  (Watcher@TMI, GateWay)
 
 
Description
-----------

The Shadow Shell system (shsh) is a user environmental overlay which allows
a user to reformat what they see on the screen into separate windows through
the use of ANSI code manipulation.  As a result, to make full use of the
shell's abilities, the user must be using an ANSI compatible terminal
emulation (ie: vt100, ANSI, etc).  Without this emulation, a user may still
make use of some shell functions, but not the core output manipulation set.

The shell is constructed as to divide a user's screen into a number of sub
windows.  These windows can be classified in one of two categories: system
window or user window.  The system window may only receive and display 
information to the user, and cannot be used by the user.  While a user
window are windows in which the user interacts, and can receive and send
communications.  There are only two system class windows: the status window
which displays status information about the user and their environment, and
the communication window which receives and displays all incoming information.
Both of these windows are optional, and may be enabled/disabled in the shell
configuration process.

The shell makes use of the MudOS message efun which passes all communcation
going through it with a tag to receive_message() within the user object.
Within receive_message() is a catch which passes the incoming communcation
to the shell where it can be reformated with respect to screen positioning,
colour, highlighting, etc and then passed back to receive_message() where
it completes the path to the user's screen.  It is this interlinking between
the shell and the mudlib that allows the shell's powerful communication
manipulation capabilities.

 
Shell Window Commands
---------------------

Before the shell can be used in window mode, it must be first configured. This
is done with the "configure shell" command, which enters the user into the
shadow shell's configuration menu system. This allows the user to designate
whether the shell will have a status window and/or a communication window,
any change in the shell's default colours, as well as the shell's default
system settings. If the user has a home directory, they will have the option
of saving this configuration in a .ssrc file. Alternatively, the shell will
maintain this configuration through the autoload system. However, the 
autoload system is limited in what it will maintain over logout, and the
use of .ssrc file allows alot more flexibility in the shell's save system.

The main shsh command is used to enter and exit from the shell's window 
mode. The arguments for this command are simply [on/off]. If shell window
mode activation is selected, it will only continue if the shell has been
configured, and the shell has been properly selected with the mudlib's chsh
command.  The shsh off command will remove all subwindows, and clear the 
user's screen, for standard interactive use.
 
If the shell layout has been disrupted by external ANSI interferance, or the
configuration has been adjusted since the shell window system has been 
activated, it can be redrawn with the "refresh shell" command. This command
will also blank out all interactive windows.
 
Additional interactive shell windows may be added to the screen layout
through the use of the "add window" command. The command will also accept
an argument which refers to the new windows line length (ie: add window 5
will open a new window five lines in size).  The command will fail if the
new window request will not fit into the present window screen configuration.

The "remove window" command will remove the latest window opened by the user
(ie: the window closest to the bottom of the screen), and use the remaining
area for the window directly above it. The command will fail if the user
attempts to remove the main interactive window (window 1) as this window
may not be removed.

The window user may also move between user windows through use of the 
change window command, or its shortcut command, /go.  The change window
command will prompt the user to input the destination window, while the
/go command accepts the new window designation as an argument (ie: /go 2
to move to window two).  Of course, this command will fail if the designated
window doesn't exist.

The final window system command is the "cls" command. This command allows the
user to clear the present interactive window, or another specified active
window. For example, by simply typing "cls", the user can clean the present
active window. Conversely, the user may clean window 2 by typing cls 2. Lastly
the communication window can be cleared by typing cls 0 or cls comm.

 
Message Manipulation Commands
-----------------------------

A specific communication string may be gagged (ie: blocked from output to
the user) through the use of the shell's gag command. For example, if the user
dislikes a talkative mobile called "Harry", they can do "/gag Harry says",
which will cause any incoming communication with "Harry says" in it to be
discarded before it reaches the user. Stored gag strings may be removed
with the use of the shell's ungag command.

Conversely to the shell's gag capabilities are its hilite capability. This
will cause the shell to hilight any incoming communication which has the
selected string within it. For example, if the user wants to make sure they
don't miss any "tell"s from Buddha, they can "/hilite Buddha tells you" and it
hilight the communication for easy use if Buddha ever tells them anything. 
If they decide not to emphasize what Buddha tells them anymore, they can 
remove it from their hilite field with the unhilite command.

Closely related to the hilite command is the shell's page command. Instead
of hilighting the incoming labelled communication, it will issue a beep
along with the message to signal the user. Once again, it can be removed
through the use of the unpage command.
 
Each incoming message has been class labelled by the mudlib to reference
that particular message type. For example, all messages coming through a
tell_object have been labelled "tell_object" by the mudlib, as has those
from the say, write, etc functions.  This class labelling allows the shell
to manipulate where it wishes to place these message types.  This is primarily
done with the shell's "assign" command.  With this command, the user may
assign a specific class of communication to a specific window.  For example,
by doing "/assign channel to 2", the shell will then display all "channel"
labelled messages in window two (if it doesn't exist, it will default back
to the communication window).  A specific class of communication can also
be automatically discarded by the shell by assigning that class to "nul"
(ie: "/assign channel to nul" will prevent any channel messages to be
blocked from being displayed).  Any window assignments may be removed by
the user through the use of the "unassign" command.

 
Socket Control Commands
-----------------------

The Shadow Shell has a base window socket support builtin, which can allow
authorized users to connect a specific window to a specific remote mud. A
connection to a remote mud is created with the shell's "open" command. Thus
a user may connect the active window to TMI-2 by typing "/open" followed by
TMI-2's present address (either numeric or alphabetic address format are
allowed).  The shell also interfaces with the mudlib's name server, so a
user may alternatively connect to TMI-2 by typing "/open tmi-2". The user
may also close an open socket connection through the shell's "close" command.
Admins should be wary about opening access to the shell's socket system to
just any wizards.  Socket telnet use provides the user with an anonymous
identity (all ip addresses for the remote user will point to the originating
mudlib), and could open the door to abuse.  Use of the mudlib's telnet daemon
to restrict where the shell may connect to is one solution. Another is to
make use of the shell's socket permission system to restrict the socket use
to trusted users.

 
Miscellaneous Shell Commands
----------------------------

The information display given by the shell's status window also displays
the current time. By default, it is displayed according the the mud's local
time. The user may user the "/time" command to set the shell's timezone
difference value so that the time value will represent their local time.
 
The "/beep" command may be used to signal a player (ie: if they are idling
and not noticing tell messages). This will send a beep to the requested
player and tell them who is signalling them. Be warned...overuse/misuse of
this command is a quick way to get oneself destructed or removed.
 
The "/fc" command toggles the shell's file completion mode on and off. The
shell allows for a limited form of filename completion, in that if a "*" is
placed*" at the end of the filename the user is trying to reference, the shell 
will try to complete the filename for them.  For example, if one wished to 
goto a room called death_valley.c, one could do goto death*, and if it was the 
only file in the current directory that matched that pattern, the shell would
complete the filename, and initiate the action. This ability only works for
filename pattern's terminating with the "*".  It will not work if the "*"
is any other position but the last in the filename.

The "/status" command produces a printout of the shell's present status,
including save method, and stored gags, hilites, and pages.

The shell "/history" command prints out the user's last 20 actions with a
corresponding number from 1 to 20.  These can then be referenced and repeated
with the shell's "/do" command.  For example, if the "/history" command listed
"finger @tmi-2" as my 15th action, I could repeat it by typing "/do 15".
These two commands have become slightly redundent as the mudlib's history
system has increased in sophistication, however I have left them in the shell
as they can be easier to use with their 1-20 listing.

Perhaps the most unpredictable command within the shell is the "/buffer"
command.  It uses the get_char() efun to produce an interactive back scroll
buffer effect, and unfortunately some telnet clients do not agree with it
resulting in very unsavory results.  For those that have clients that like
the get_char() efun, the "/buffer" command allows one to scroll back through
the past received communcations, in an interactive manner. The "u" key will
move one back up the scroll buffer, while "d" will move one back down. The
"q" or ESC key will close the buffer and return one to standard interactive
window mode. Better support for those with get_char()-hating clients will
be offered in the next release.

The shell also has a builtin alarm system, in that the user can request the 
shell alert them with a preset message and signalling beeps after a preset
time period in minutes has passed.  For example, if the user realized they had 
to leave to catch a bus in 20 minutes, and didn't want to forget about it
while mudding, they could simply do "/alarm 20 Go catch the Bus!".  Thus,
after 20 minutes, the shell will signal the user with the appropriate message.
The shell can save up to 5 alarm notifications at one time.
 
 
Quick Start Procedure
---------------------

To begin using the Shadow Shell, the first thing one must do is to select
the shell as their interactive shell environment.  This is achieved with
the mudlib's "chsh" command, and by typing "chsh [shell filename]". Generally
the filename is "/obj/shells/shsh.c", but this may be different on the local
mud. One can obtain a full list of available environment shells by typing
"chsh ?".  Once the shell has been selected, it may then be configured
with the "configure shell" command.  Once done, the user can activate
the shell's interactive window mode with the "shsh on" command.
With this command, the screen should be reformated, and the user is ready 
to explore the world in the new shell environment. If the shell ever becomes
lost for some reason, it can be retrieved with the mudlib's "shell" command.
The "help shell" command will also provide the user with a brief help listing.

 
Relate Commands
---------------

Refer to the mudlib's chsh and shell commands for shell related systems.