home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.26 / text0065.txt < prev    next >
Encoding:
Text File  |  1992-02-21  |  2.2 KB  |  51 lines
  1. Submitted-by: bvs@bitblks.BitBlocks.COM
  2.  
  3. Dan Bernstein writes:
  4. > bdiff, cmp, comm, diff, diff3, join, look, more, nohup, pr, sdiff, tee,
  5. > and touch can be written to work with file descriptors under v7. Under
  6. > BSD, the syscalls for working with descriptors are more complete, so you
  7. > can do chgrp, chmod, chown, etc. without explicit filenames.
  8.  
  9. I don't see a fundamental conflict between making these programs
  10. work with file descriptors (actually, `handles') and wanting a
  11. naming scheme where every object of interest can be accessed by
  12. a name.  Not every file operation makes sense on every object but
  13. that is okay.  Just as write() to a directory does not make sense,
  14. chmod() of a network connection does not either.  Naming is
  15. orthogonal to what operations make sense on an object or even,
  16. whether the object is long-lived or temporary.
  17.  
  18. What many people (including me) are saying is that we want to
  19. access more kinds of objects than those provided by a traditional
  20. unix filesystem and we want a unified approach to accessing these
  21. objects.
  22.  
  23. This does not mean implementing all of these new mechanisms in the
  24. unix kernel.  Far from it.  Any one should be able to attach a
  25. name-space object (a directory, but that has taken on too specific
  26. a meaning) into the existing naming hierarchy.  Not all objects
  27. may be directly named in a given namespace (e.g. the namespace of
  28. internet services) but so what?
  29.  
  30. I agree with Dan that the existing file protection system is not
  31. appropriate for network connections and that a more general scheme
  32. needs to be worked out; but it does not invalidate the usefulness
  33. of a uniform naming hierarchy.
  34.  
  35. > The pure solution is to have every program keep a file descriptor around
  36. > for talking to the shell. Then requests for opening files can be
  37. > shuttled down that descriptor.
  38.  
  39. Replace the `shell' with the root of the naming tree and we are in
  40. agreement!  Given that any one can use any `shell' we can't depend
  41. on having a specific shell around.  Besides, the job of a shell is
  42. to interpret user commands; it should not be in the business of
  43. implementing super-open -- UNIX philosophy(tm), you know :-)
  44.  
  45. -- Bakul Shah
  46. bvs@BitBlocks.COM           or          ..!uunet!amdcad!light!bvs
  47.  
  48.  
  49. Volume-Number: Volume 26, Number 76
  50.  
  51.