home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.22 / text0006.txt < prev    next >
Encoding:
Text File  |  1991-03-06  |  1.3 KB  |  38 lines
  1. Submitted-by: addw@phcomp.co.uk (Alain Williams)
  2.  
  3. > I agree; it makes things like 
  4. > 
  5. >     join <(prog1) <(prog2) > joined-output-of-progs-1-and-2
  6. > 
  7. > possible.
  8. Such things are possible *now*, you don't need /dev/fd to do it, just an
  9. intelligent shell that doesn't mind making & destroying fifos.
  10.  
  11. Anyway, the above wouldn't work with a straight /dev/fd as has been talked about
  12. here recently. Why ? The trouble is that if /dev/fd contains files with
  13. names "0", "1", ... "19", the programs prog1 & prog2 would both have a file
  14. /dev/fd/1 as their stdout, join would see another /dev/fd/1.
  15.  
  16. What is really needed to do what is suggested above is for /proc to contain
  17. an fd directory, thus the command line above would be ``re written'' by the
  18. shell to something like:
  19.  
  20.     join /proc/1234/fd/1 /proc/1235/fd/1 > joined-output-of-progs-1-and-2
  21. (where 1234 & 1235 are the process ids of prog1 and prog2).
  22.  
  23. If we adopt the /proc/nnn/fd idea, more questions are raised, for instance what
  24. are the file permissions on /proc/nnn/fd ?
  25.  
  26. Let me remind the original purpose for which /dev/fd was proposed:
  27. provide a mechanism whereby programs could handle `-' to mean stdin/out
  28. as does cat, but without trying.
  29.  
  30. Alain Williams
  31.  
  32. +44 734 461232
  33.  
  34. phLOGIN our Turnkey Security Login utility is available NOW - ask me for info.
  35.  
  36. Volume-Number: Volume 22, Number 7
  37.  
  38.