home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.26 / text0049.txt < prev    next >
Encoding:
Text File  |  1992-02-21  |  3.1 KB  |  63 lines
  1. Submitted-by: sef@kithrup.COM (Sean Eric Fagan)
  2.  
  3. In article <1991Dec20.065940.11851@uunet.uu.net> brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein) writes:
  4. >Many people share this ``expectation.'' I don't understand why. Is it
  5. >because of ``the UNIX philosophy''? Or because a super-open() is
  6. >supposed to be easier for programmers? Or for users?
  7.  
  8. Possibly both.  Having everything as a simple byte sequence certainly makes
  9. some things easier (although, to be honest, it makes other things more
  10. difficult).
  11.  
  12. You bring up the concept of pipes, which didn't exist as files in the
  13. original systems.  Well, a lot of things weren't in the original systems
  14. originally, either, and lots of people seem to think that some of the
  15. additions since V7 were a good idea.  (The problem is that most of these
  16. people don't agree that *all* of the additions were a good idea, and they
  17. all have different ideas about what *was* a good idea to add 8-).)
  18.  
  19. I am currently discouraged that I can't create a socket in my filesystem;
  20. there are things where it would be nice to do so.  Oh, I can kludge around
  21. it, by making a named pipe, and using rsh/rcmd.  But a named TCP/IP socket,
  22. to a specified host, would be nice.  (E.g., cp
  23. /tcp/ip/ftp/uunet.uu.net/ftp/ls-lR.Z .)
  24.  
  25. Unix also has the idea of unnamed files; normally, these are things like
  26. sockets or pipes, but they can also be files that were created, and then
  27. unlinked.  Can you come up with a good reason (excluding efficiency, which
  28. I'll mention in a bit) *not* to support the creation a named pipe in the
  29. filesystem, forking, and then unlinking it, but keeping it open?  Yes, this
  30. would be somewhat less efficient:  doing a mknod(), which also involves
  31. going through the filesystem, then doing an unlink(), which is twice as many
  32. system calls as pipe().
  33.  
  34. The question is:  is this amount of generalization worth it?  I'm not sure.
  35. I think that it would probably be good for a research system (and, then,
  36. maybe moving it into commercial systems, if the advantages are enough), but
  37. I can't heartily agree with it.  Or disagree with it.
  38.  
  39. I'm not saying I disagree with Dan.  I'm just not saying I agree with him.
  40. (I feel like Charlie Brown:  "I'll be wishy one day, and washy the next!")
  41.  
  42. Tell me, Dan, how do you feel about the /dev/fd filesystem/pseeudo devices?
  43. As you point out, having every process know that it should use
  44. filedescriptor 0 for input, 1 for output, and 2 for error reporting has made
  45. a lot of things very easy for Unix and Unix programmers.  (And 3 as the "tty
  46. device" is something that I don't necessarily agree with, but Plan 9 papers
  47. seem to report that it has worked out pretty well.)  By having the file 
  48. descriptors available in the filesystem name space, it makes some things a
  49. lot easier.  E.g., "vi /dev/fd/0"  (Ok, that's stretching it.  How about
  50. ksh's use of it:  "sed <$(foo1) <$(foo2) <$(foo3)"  Using named pipes, of
  51. course, would do the same thing, except you'd have to clean them up
  52. afterwards.)
  53.  
  54. -- 
  55. Sean Eric Fagan
  56. sef@kithrup.COM
  57.  
  58. [ I'm going to ask people to use their judgement on this thread.  It might
  59.   belong in one of the comp.unix groups instead of here.  -- mod ]
  60.  
  61. Volume-Number: Volume 26, Number 51
  62.  
  63.