
- additional issues:

  - missing dependency for shell.h?
  - should not return an error message in client if command is not found
  - server input needs to place files for input on a stack which is 
    actually loaded by the RunScheduler loop
  - have the client run a special multicommand function which passes 
    any unfound commands along to the server.  the server should not 
    be running multicommand, but it probably does not hurt.
    (the client is not allowed to send ';' to the server)
  - the multicommand needs to be available in the 'for' and other loops
    this probably means unifying the client and non-client forms.  
    how does multiclient get the value of the server?  I tend to use
    globals for things like that, which is probably not the best 
    practice.  is the client form of the tool generic? are there other
    circumstances which would use a client/server beyond pantasks?
    maybe pcontrol?  

    the two pieces of information which need to be carried to the
    multicommand and command functions in client/server mode are the 
    server socket and the verbosity of the error messages.  these could
    be defined on startup with globals and an init function of some sort.

I need to do some serious work on the output messages in order 
to support the client/server interactions.  In client/server mode,
all of the output messages to be sent back to the client need to be
saved in a buffer and then pushed back to the client after the command
is executed.  Currently, I can select only the output file pointer.
this is not sufficient.  I need to supply a function which will write to 
an internal buffer until a 'dump' function is called, or something
equivalent.  

in client/server mode, the commands issues by the client (except as noted 
below) all return immediately.  The output produced by those commands
is saved by the server until the command is finished, then the
resulting buffered data is pushed back to the client.  There a few
commands which behave a bit differently.  these commands are in the
background thread of the scheduler.  the resulting output is sent to
the logger device of the scheduler rather than back to any specific
client.  should there be a way for the client(s) to examine the
scheduler output? 

- pantasks input: this passes an 'input' command to the server, which
  performs the input in a different thread.  is this the same thread
  as the scheduler loop?  another option within the scheduler loop?

- run
