home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0048.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  1.4 KB  |  32 lines
  1. Submitted-by: brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein)
  2.  
  3. Under BSD, you can easily set up a /inst/bin directory with symlinks to
  4. every officially ``installed'' executable. Users can then have /inst/bin
  5. in their paths instead of all the physical directories like /bin, /etc,
  6. /usr/bin, /usr/ucb, etc. Although the directory is large, the time for
  7. several failing execve()s is much larger than the time for searching one
  8. directory (especially with path caching as in BSD 4.3).
  9.  
  10. Even on System V, you can put hard links in /inst/bin, and when an
  11. executable is on a different device you can set up a shell script which
  12. execs the real executable. It's *still* more efficient, on the average,
  13. than all the failing execve()s. Try it if you don't believe me.
  14.  
  15. Yes, this requires all executables to be given unique names. Any concept
  16. of a standard path, including the POSIX.2 proposal, forces this. It's
  17. simply not a disadvantage.
  18.  
  19. Anyway, as vendors haven't come to any agreement on this facility---the
  20. current ``standard'' is to install most programs somewhere under
  21. /usr/local, with new subdirectories for big programs like ingres---I
  22. despise POSIX's attempts to name any particular solution a ``standard.''
  23. In the interests of security, efficiency, and backwards compatibility, I
  24. propose /inst/bin as a viable alternative to getconf. I suggest that
  25. POSIX look---and take its time looking---before it leaps.
  26.  
  27. ---Dan
  28.  
  29.  
  30. Volume-Number: Volume 24, Number 49
  31.  
  32.