home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.28 / text0028.txt < prev    next >
Encoding:
Text File  |  1992-08-17  |  2.1 KB  |  47 lines
  1. Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  2.  
  3. In article <11k9bsINN6n9@ftp.UU.NET> peter@ferranti.com (Peter da Silva) writes:
  4. >A better design still would be to make the current directory a standard
  5. >file descriptor, ...
  6.  
  7. Well, yes, that's an interesting approach.  One problem is that it
  8. would require (at the program/OS interface level) that open() of any
  9. directory work properly, which currently isn't guaranteed in some
  10. implementations.
  11.  
  12. Anyway, my strategic concern is that we look to improved design to
  13. solve problems rather than worry excessively about making existing
  14. inferior designs work marginally better.  In my view that is the
  15. original policy that produced the UNIX system that we old-timers
  16. admired.  One acknowledged problem with standardization of existing
  17. practice is that it locks in inferior technology and provides an
  18. economic disincentive to find better methods.  Thus we probably have
  19. to look to research platforms (Plan 9 comes to mind, but there are
  20. others) or non-POSIX OSes rather than commercial UNIX for substantial
  21. innovations.
  22.  
  23. >I also think argv and envp should be passed in on yet another standard
  24. >file descriptor as well... let's simplify the design rather than complicate
  25. >it.
  26.  
  27. Unfortunately the C standard has locked in argv.  (You're not supposed
  28. to use envp.)  The environment could also be implemented as /dev/env/*
  29. (for example, with "*" being the "names" and their contents the "values"),
  30. to be opened and modified if one needs it.  There is some trade-off
  31. between opening standard services via standard pathnames and having
  32. them preopened on standard FDs.  (I don't know without more thought
  33. just what the important trade-offs are!)
  34.  
  35. >What operating system is this?
  36.  
  37. For the curious, Apple's ProDOS and GS/OS implement path prefixes,
  38. and I've layered support for UNIX conventions (/, .., .) into my
  39. edition of the standard C library.  The code that handles this is
  40. generic and isolated into its own module; if somebody would like to
  41. experiment with it I should be able to make it available.  Actually
  42. it shouldn't be very difficult to reimplement yourself.
  43.  
  44.  
  45. Volume-Number: Volume 28, Number 29
  46.  
  47.