NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/unix/programm/3978

Text File | 1992-07-28 | 1.8 KB | 46 lines

Newsgroups: comp.unix.programmer
Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!machine!chinet!les
From: [e-mail] (Leslie Mikesell)
Subject: Re: Named pipes
Message-ID: <[e-mail]>
Organization: Chinet - Public Access UNIX
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Tue, 28 Jul 1992 19:46:27 GMT
Lines: 35

In article <[e-mail]> [e-mail] (Charles Hannum) writes:
>
>> mknod testpipe p
>> cat testpipe &
>> ls > testpipe
>> The "cat" process ends after the ls is sent to the screen.

>This is the way named pipes have worked since The Dawn of Time.  If you
>want to have multiple processes write to the pipe, you need the reader
>to reopen it.  In the shell, you could do something like this:
>(while :;do cat testpipe;done)&

Cat just happens to be written to exit when it hits EOF.  So, either
prevent it from seeing EOF by holding the write side open with an
unused fd:
  cat testpipe 4>testpipe &
or use a process that doesn't exit at EOF.  Just be sure it sleeps
a while between reads when there is no input.  A shell script that
periodically reads a control fifo makes a handy server:
do
 read A B
 ..process control command (if any) ..
 ..do some work...
done < fifo

You just have to start it in the background and throw it a real or
dummy command command to unblock its open on the fifo, then you
can "echo command argument > fifo"  manually or from other programs
to control it.  (Try that with sockets...).  If you want it to
wait for each command, open for write also ( done <fifo 4>fifo)
otherwise the reads are non-blocking after the fifo has been
opened and closed by a writer.

Les Mikesell
  [e-mail]