Hi there,

This release contains the following:
    pipe_create.c   
    pipe_delete.c
    pipe_receive.c
    pipe_send.c
These files are described below.  They were almost totally lifted from
the Sun IPC doccumentation and were tested on a Sun 10/30 running
SunOS 4.1.3.  I don't know if they work on other platforms, and I am
by no means a professional.  I understand that the description below
may be above many of your levels, but I wrote it up for someone else
and didn't feel like changing it much.  These 4 programs together form
programs that work standalone.  I suggest you make sure they work
before messing around with the gnuplot source.  After they're compiled,
here's what to do:
    pipe_create  (creates pipe)
    pipe_send PIPE_NUM message (sends message of type PIPE_NUM) on pipe
    (in another window (more impressive that way)) pipe_1_receive
    (in yet another window) pipe_2_receive
    pipe_send 1 message (to your heart's content)
    pipe_send 2 message (to your heart's content)
    pipe_send 1 quit (to quit the first receive program)
    pipe_send 2 quit (to quit the second receive program)
    pipe_delete (kill the pipe)
Other files:
    Makefile (to make the above utilities)
    patch01
The file patch01 contains the changes to misc.c and plot.c so that you
can use the IPC stuff in gnuplot.  Basically, the patch to plot.c just
checks if the first argument on the command line is "-ipc" and if it is,
it then calls the procedure in misc.c to interpret commands from the pipe
instead of from stdin (the code in misc.c is almost exactly like that
in pipe_receive.c).  Make sure to call the following if you're planning
on using ipc:
    pipe_create
    gnuplot -ipc &
    pipe_send 1 commands
    pipe_send 1 quit (stops pipe and exits gnuplot)
    pipe_delete
I have defined pipe #1 as the gnuplot pipe, but that could easily be
altered.  If you wanted, you could just change the code in plot.c to
read the pipe number as the second argument if the first is -ipc, and
then change the code in misc.c to reflect that change.  In this way, you
could have two separate gnuplot processes continually running and you
could have them do different stuff simultaneously.  DON'T FORGET TO
QUIT ALL RUNNING GNUPLOTS IN IPC-MODE BEFORE DELETING THE PIPE.  (see
below in Notes).  Oh yeah, I made this patch from version 3.2, patchlevel
2 and didn't write anything to change the patchlevel, etc.  The changes
are relatively simple, however, and shouldn't be difficult to implement
in any other version/patchlevel.
I guess that's it.  Have fun.

 - Dave Walton (dwalton@monosparc.mit.edu)

Here's a brief description of the IPC stuff...
First, IPC stands for Inter-Process Communications.  It's a way in 
UNIX for programs to share information.  There are basically three 
different ways they can communicate.  The first is by way of a pipe 
along which messages can be sent and received (That's what I used).  
The second is by way of semaphores (I haven't really looked at that).  
And the third way is by sharing memory (That's messy!).

What I did was split the IPC stuff into 4 relatively simple routines, 
as follows:

pipe_create:
    This routine creates the pipe (if it isn't already created).  
It calls msgget, which gets a new pipe.  The first parameter to this 
call is ftok("/tmp",'A'), which creates a key on the /tmp file.  Any 
file could be used (and a number could be typed in), but this way, 
you don't need to know the number explicitly, and the /tmp file always 
exists.  The second parameter to this call is a bunch of flags telling 
how to open the pipe.  IPC_CREAT tells the routine to create a new pipe.  
IPC_EXCL tells the routine only to create the pipe if it doesn't already 
exist.  0600 is the permission of the pipe, just as set with chmod.  
(i.e. 0600 means read/write by owner.  Note, the preceding 0 is important 
as this signals to C that you're entering the value in octal mode.)  
The return value, msqid, is the pipe number which will be used by all 
subsequent calls to the pipe.  A return value of -1 means something 
went wrong.

pipe_delete:
    This routine deletes the pipe (if it exists).  It first calls 
msgget to make sure that the pipe exists.  If it does, it returns 
a value of msqid which is not -1, and we then call msgctl with the 
flag IPC_RMID which deletes the pipe.  If the call returns -1, 
something went wrong.

pipe_send:
    Although this may look a little messy, the method is rather straight 
forward.  First, we're going to make sure the pipe is open.  Then we're 
going to allocate enough memory for the message.  Then we're going to 
assign a type to the message.  (You can send many different message 
types along the pipe, and since each receiving side of the pipe will 
look for only a specific type of message, this simulates multiple pipes.)  
Finally we're going to put the message on the pipe and hope that someone 
else will pick it up.
    The usage of this command is to send the message type as the first 
parameter and the text as all subsequent parameters.  Message types must 
be positive integers.  Remember that UNIX will try to interpret any 
special characters unless their codes are explicitly sent:
    	pipe_send 1 Did he say "Hi there" ? 	will give an error
    	pipe_send 1 Did he say \"Hi there\" \?  will work
    First call msgget to make sure that the pipe exists (as in 
pipe_delete).  Second, allocate enough memory for the message with 
malloc.  (I don't free up the memory at the end.  This is done
automatically when the program exits.  I also assumed that no 
messages will be over 256 characters long.)  Next set the message 
type in the mtype entry of the control structure using the first 
command-line argument.  Next build a string with all of the subsequent 
command-line arguments and save only the first 256 characters in the 
mtext entry of the control structure.  Then send the message and don't 
wait for anything to happen (IPC_NOWAIT) except for the return of any 
errors that may occur.

pipe_receive:
    This routine is also rather simple.  Basically, it knows it's looking 
for messages of a certain type, and it just sits there waiting for them 
and printing them out until the word "quit" comes along the pipe.
    First, we make sure that the pipe is open with msgget.  Next we
 allocate memory with malloc for any message that may come along the 
pipe with message type PIPE_NUMBER.  And then we wait until something 
comes along with the desired number and we print it out.  It is important 
to note that even though the messages are sent along the pipe and are 
queued up (i.e. fifo), if you mix types of messages on the pipe, it is 
not necessary to flush a message of a different type that may be ahead 
of one you want to get.  (i.e. if you have messages of the following 
types queued up:  2 1 1 4 3 2 1 2 2 and you run pipe_receive with 
PIPE_NUMBER = 1, all of those messages will be flushed and the pipe 
will then contain: 2 4 3 2 2 2.)  This routine could easily be modified 
so that you could take the message type argument from the command line, 
but I deliberately wrote it like this so that you could simply lift the 
code and put it in some other program which desires this capability.

Notes:
1) A "msgget failed: File Exists" error message from pipe_create means 
that the pipe already exists.
2) Don't kill the pipe (pipe_delete) while pipe_receive is running, or 
you'll get many "msgrcv failed: No Such File" (or something like that)
passing before your eyes.  If this happens, you need to go to another 
window and type:
    ps -acux | grep pipe_receive
Then extract the PID number (should be 2nd column) and type
    kill PID_number
