Re: Full duplex connections (pipes)

[haahr@mv.us.adobe.com (Paul Haahr)]

> Many moons ago I suggested that it would be nice if you could background
> a process and communicate with it from your command line, thus allowing
> an MH-like interface to be plugged into any process you wanted

doing an mh-style (``the shell is my only command interpreter'') interface
to things is great; if you want to build it on top of other tools, those
tools probably need to be structured very intelligently and flexibly.
you probably want your programs pre-structured as ``server'' processes.

the idea of being able to put new interfaces on old programs is great.
but, you've got to deal with complex output:  for bc this isn't much
of an issue, and i've never used gnuplot, but dbx has nightmare output,
enough so that sun had to add a new output format and command line
option (-P? -R?) when they did their mouse-based interface to it.

a shell is probably not the appropriate place to do the filtering
that goes on inside the tools.

on the other hand, Don Libes' expect program is a real win, i think.
it's set up to control other programs, and, with sufficient cleverness,
allows you to handle the input/output of any child process, from dbx
to a rogue game.  the reason it works is you write programs in a real
language (tcl) to parse the output and make decisions.  you could probably
set up expect to act as a background (server) process and just have
a simple (c or perl or hacked-es) program which writes a message to
the expect process and gets one back for printing to the user.

one other difficulty doing this is buffering on pipes.  socket-based
pipes are much better in this regard, i think, but traditional unix
pipes would cause things to lock up.  i'm pretty sure that expect
uses pseudo-ttys, which lack this problem.

paul

ps:  sorry if this note rambles.  i'm not awake yet.