home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.28 / text0029.txt < prev    next >
Encoding:
Text File  |  1992-08-17  |  3.1 KB  |  70 lines
  1. Submitted-by: peter@ferranti.com (Peter da Silva)
  2.  
  3. In article <11r3dbINN6q7@ftp.UU.NET> gwyn@smoke.brl.mil (Doug Gwyn) writes:
  4. > Submitted-by: gwyn@smoke.brl.mil (Doug Gwyn)
  5. > 
  6. > In article <11k9bsINN6n9@ftp.UU.NET> peter@ferranti.com (Peter da Silva) writes:
  7. > >A better design still would be to make the current directory a standard
  8. > >file descriptor, ...
  9. > 
  10. > Well, yes, that's an interesting approach.  One problem is that it
  11. > would require (at the program/OS interface level) that open() of any
  12. > directory work properly, which currently isn't guaranteed in some
  13. > implementations.
  14.  
  15. Yes, you would need to implement an "O_DIR" mode that would work on any
  16. directory, though the behaviour of read() and write() on a file with O_DIR
  17. only would be undefined.
  18.  
  19. > Anyway, my strategic concern is that we look to improved design to
  20. > solve problems rather than worry excessively about making existing
  21. > inferior designs work marginally better.
  22.  
  23. I can accept that goal, I'd just like to point out that your suggestion
  24. (was it your suggestion?) that the operating system track current working
  25. directory is not necessarily an improved design. It simplifies one
  26. particular operation that is not frequently used (and in fact only need
  27. ever be called once by any given program) and complicates a number of
  28. other things (for example, having two programs call getcwd() and return
  29. different values). In addition, it can be easily emulated in the runtime
  30. if you *do* want to do it simply by caching the first getcwd() and then
  31. tracking changes to it. My suggestion is more generally useful, and also
  32. makes getcwd() simpler to implement. In my opinion, that makes it a superior
  33. design.
  34.  
  35. > >I also think argv and envp should be passed in on yet another standard
  36. > >file descriptor as well... let's simplify the design rather than complicate
  37. > >it.
  38.  
  39. > Unfortunately the C standard has locked in argv.
  40.  
  41. crt0 can extract an argv from stdcmd.
  42.  
  43. Another advantage of stdcmd is that programs that are written for it can
  44. accept multiple sets of arguments on it, allowing interactive control. This
  45. would be extremely useful for a windowing shell, plus it would obviate the
  46. need for xargs and similar kludges.
  47.  
  48. > (You're not supposed
  49. > to use envp.)  The environment could also be implemented as /dev/env/*
  50.  
  51. This is actually how it's implemented on the Amiga. In fact, the initial
  52. intent was that ENV: would be a special purpose file system, but it turns out
  53. that simply assigning ENV: to RAM:ENV works as well on a single-user system.
  54. This is the sort of nice trade-off you get when you can go back to basics.
  55.  
  56. > For the curious, Apple's ProDOS and GS/OS implement path prefixes,
  57. > and I've layered support for UNIX conventions (/, .., .) into my
  58. > edition of the standard C library.
  59.  
  60. So other people's programs don't see these conventions?
  61. -- 
  62. Peter da Silva                                                      `-_-'
  63. $ EDIT/TECO LOVE                                                     'U` 
  64. Ferranti International Controls Corporation                    Have you hugged
  65. Sugar Land, TX  77487-5012    +1 713 274 5180                  your wolf today?
  66.  
  67.  
  68. Volume-Number: Volume 28, Number 30
  69.  
  70.