Re: FIFOs again

[Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxxx>]

> First, current docs are a bit incorrect. Shell passes FIFO or /dev/fd/n,
> which is in reality pipe (if I understand implementation correctly). So,
> both are not seekable, while docs imply, that only FIFO case is not.

Ah, you mean because zsh supplies a pipe between the forked processes
even if the device file is a real live file descriptor.

Index: Doc/Zsh/expn.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/expn.yo,v
retrieving revision 1.17
diff -u -r1.17 expn.yo
--- Doc/Zsh/expn.yo	2000/05/22 15:01:35	1.17
+++ Doc/Zsh/expn.yo	2000/05/24 12:56:17
@@ -320,13 +320,13 @@
 the former case, some programmes may automatically close the file
 descriptor in question before examining the file on the command line,
 particularly if this is necessary for security reasons such as when the
-programme is running setuid.  In the second case, the file passed as an
-argument to the command is a system pipe, so programs that expect to lseek
-(see manref(lseek)(2)) on the file will not work; furthermore, if the
+programme is running setuid.  In the second case,  if the
 programme does not actually open the file the subshell attempting to read
 from or write to the pipe will (in a typical implementation, different
 operating systems may have different behaviour) block for ever and have to
-be killed explicitly.
+be killed explicitly.  In both cases, the shell actually supplies the
+information using a pipe, so that programmes that expect to lseek
+(see manref(lseek)(2)) on the file will not work.
 
 Also note that the previous example can be more compactly and
 efficiently written (provided the tt(MULTIOS) option is set) as:

-- 
Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxxx>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070