home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.26 / text0064.txt < prev    next >
Encoding:
Text File  |  1992-02-21  |  2.6 KB  |  53 lines
  1. Submitted-by: peter@ficc.ferranti.com (peter da silva)
  2.  
  3. I think Dan has a couple of basic problems in his argument here: first,
  4. looking at extensions to the file system as extensions to "open"; and
  5. second, missing the huge amount of code that comprises the "normal" UNIX
  6. environment that depends on a uniform name space. Because of this uniform
  7. name space, you can change the behaviour of a program (which may well be
  8. a shell script) by changing the name of a file.
  9.  
  10. For the first of these problems, it's not just "open" that operates on
  11. files.  It's "creat", "mknod", "link", "chmod", and so on. All these
  12. calls have to be expanded, duplicated, or replaced. Or you can simply go
  13. down a level of indirection and change "namei"... and, in fact, virtually
  14. every version of UNIX has done this in one way or another. The
  15. "watchdogs" that he refers to are one implementation of what he's arguing
  16. against.
  17.  
  18. If this namespace is splintered by creating a whole bunch of different
  19. methods of opening streams, then you lose this capability. You suddenly
  20. need to coordinate with the shell ever time you want to refer to a
  21. file... the shell actually becomes the "super open" Dan's complaining
  22. about.
  23.  
  24. Correspondingly, if this namespace is strengthened by adding new types of
  25. streams to it, the system becomes more powerful. As an *example* of this,
  26. I brought up AmigaDOS: which has taken this basic concept and extended
  27. it. In fact, many of the AmigaDOS facilities have been copied from UNIX.
  28.  
  29. Another problem with Dan's suggestions is that they reduce the name space
  30. available for normal files: a name space that's already hurt by the UNIX
  31. option syntax. If you start defining "3" to mean file descriptor 3,
  32. you're going to run into problems if you "cd /usr/spool/news/comp/std/unix" 
  33. and then type "more *". If you make that "#3", then the namespace 
  34. collision gets less critical, but it's still a problem. This is basically 
  35. what MS-DOS does with the special file names "CON", "PRT", and so on... 
  36. and it gets real old real fast.
  37.  
  38. We also have some red herrings, but I think Sean has pretty well
  39. addressed them already in his posting. One he missed is this:
  40.  
  41.     "How about this: Pipes don't belong in the filesystem. Some 
  42.     UNIX variants swap pipes out to disk, but most don't."
  43.  
  44. Whether a pipe is implemented using disk blocks or not is a completely
  45. separate concept from whether it's visible in the file system.
  46.  
  47. [ Ok.  I am posting this here because it is attempting to discuss a basic
  48.   philosophy of UNIX et al.  Once again, I have crossposted this to
  49.   comp.unix.internals, and set followups there. -- mod ]
  50.  
  51. Volume-Number: Volume 26, Number 75
  52.  
  53.