home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0050.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  2.8 KB  |  62 lines
  1. Submitted-by: karish@mindcraft.com (Chuck Karish)
  2.  
  3. In article <1991Jul17.195136.29019@uunet.uu.net> brnstnd@KRAMDEN.ACF.NYU.EDU
  4. (Dan Bernstein) writes:
  5. >Under BSD, you can easily set up a /inst/bin directory with symlinks to
  6. >every officially ``installed'' executable. Users can then have /inst/bin
  7. >in their paths instead of all the physical directories like /bin, /etc,
  8. >/usr/bin, /usr/ucb, etc. Although the directory is large, the time for
  9. >several failing execve()s is much larger than the time for searching one
  10. >directory (especially with path caching as in BSD 4.3).
  11.  
  12. This might be a workable optimization on some implementations.
  13. I don't see the significance to standards of the
  14. implementation details of your shell.  There's no reason why a
  15. shell has to find a utility by trial and error.
  16.  
  17. >Anyway, as vendors haven't come to any agreement on this facility---the
  18. >current ``standard'' is to install most programs somewhere under
  19. >/usr/local, with new subdirectories for big programs like ingres---I
  20. >despise POSIX's attempts to name any particular solution a ``standard.''
  21. >In the interests of security, efficiency, and backwards compatibility, I
  22. >propose /inst/bin as a viable alternative to getconf. I suggest that
  23. >POSIX look---and take its time looking---before it leaps.
  24.  
  25. Dan, do you really understand what getconf does?  I fail to see
  26. how its use (properly protected) can make any program less
  27. portable.  It's a utility to return information about system
  28. limits and options, only one of which is a path.  It's the
  29. POSIX.2 utility-level interface to the C functionality provided
  30. by sysconf() and pathconf().  A blanket condemnation of getconf
  31. based on your idea of the correct default path for installing
  32. third-party software is nonsensical.
  33.  
  34. If your complaint is that the definition of _CS_PATH will
  35. prevent the system administrator from performing the
  36. optimization you suggest, I don't think you've thought the
  37. problem through. If you want programs, including
  38. vendor-supplied shell scripts, to use /inst/bin, move the
  39. vendor-supplied getconf aside and provide your own version that
  40. supplies your path for _CS_PATH and calls the original getconf
  41. for other values.
  42.  
  43. If vendors use "getconf _CS_PATH" consistently, they'll make it
  44. easier for you to implement your scheme.  Changing getconf will
  45. optimize PATH searching for all the system's scripts, as well
  46. as for your interactive users.  No hacking required when you
  47. install a new release, either.
  48.  
  49.  
  50. A puzzle for the reader (maybe this is obvious to everyone but
  51. me):  How can a shell script determine whether it's running on
  52. a POSIX.2 system?  If it calls getconf and getconf does not
  53. exist, the shell may exit.  It could call getconf in a
  54. subshell, but that's ugly and expensive.
  55. -- 
  56.  
  57.     Chuck Karish        karish@mindcraft.com
  58.     Mindcraft, Inc.        (415) 323-9000
  59.  
  60. Volume-Number: Volume 24, Number 51
  61.  
  62.