home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.26 / text0060.txt < prev    next >
Encoding:
Text File  |  1992-02-21  |  2.9 KB  |  73 lines
  1. Submitted-by: sef@kithrup.COM (Sean Eric Fagan)
  2.  
  3. In article <1992Jan8.231229.23299@uunet.uu.net> brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein) writes:
  4. >But pipes *still* aren't in the filesystem in any popular UNIX variant.
  5.  
  6. You mean like xenix?  (200k installed systems, as far as I know, all of them
  7. have named pipes.  SunOS has named pipes; SysV has named pipes.  Which of
  8. these is not "popular" by your definition, Dan?)
  9.  
  10. >The proponents of super-open() seem to want to be able to create new
  11. >files, new TCP connections, and so on with a single system call. *How is
  12. >open() going to create new pipes*? 
  13.  
  14. How is open() going to create a directory?
  15.  
  16. >So put it into your shell! There's nothing stopping you. tcsh sources
  17. >are freely available.
  18.  
  19. That doesn't help any other case, Dan.  Such as a program wanting to open up
  20. a connection to some other site.  I guess you're advocating using popen()
  21. instead of open for every case, right?  (After all, you can do
  22.  
  23.     FILE *fp = popen ("cat < file", "r");
  24.  
  25. instead of using open() or fopen() directly, right?)
  26.  
  27. >How about this: Pipes don't belong in the filesystem. 
  28.  
  29. Circular arguments are pretty weak for someone as bright as you, Dan.  You
  30. are welcome to argue that pipes don't belong in the filesystem because they
  31. don't belong there, but you won't win many debates or arguments that way.
  32.  
  33. >What if you don't have a
  34. >directory available for the mknod()? 
  35.  
  36. What if you don't have a directory available for any open()?  *Gasp*!  You
  37. may have to use tmpnam()!  Will the world survive this?
  38.  
  39. >Anyway, I don't think named pipes are really
  40. >relevant to the discussion; you don't create a *new* pipe through the
  41. >filesystem when you open() a named pipe.
  42.  
  43. That's nice.  You used to not be able to create a new file when you open()ed
  44. it, either; that's what creat() was for, remember?  How long was it before
  45. BSD had a version of open() that would create the file if desired?
  46.  
  47. >The question is: Has this amount of generalization appeared in any
  48. >popular UNIX system, let alone a sufficient number of systems that we
  49. >can honestly call it an industry standard?
  50.  
  51. Plan 9.  Version 8.  BSD 4.4 will probably have a /proc, SysVr4 already
  52. does.  SunOS, 4.4, SysVr4 all have the means to support this type of 
  53. generalization, and someone, at some point, will probably write a "network
  54. filesystem" (not NFS, but of the type "/network/host/port") for one or more
  55. of them.
  56.  
  57. There was a proposal, a year or so ago, to create a 'fdlink()' system call,
  58. that would create a name in the filesystem for any given file descriptor.
  59. At the time, I was against it, as the description was vague enough and I
  60. didn't see the advantage.  I've since relaxed my position a bit:  I can
  61. understand the use for it, and even see some things that you cannot do
  62. without it.
  63.  
  64. This is, as Dan stated, getting away from the topic.  I'm going to crosspost
  65. to comp.unix.internals and set followups there.
  66.  
  67. -- 
  68. Sean Eric Fagan
  69. sef@kithrup.COM
  70.  
  71. Volume-Number: Volume 26, Number 71
  72.  
  73.