home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.24 / text0057.txt < prev    next >
Encoding:
Text File  |  1991-09-03  |  4.0 KB  |  87 lines
  1. Submitted-by: karish@mindcraft.com (Chuck Karish)
  2.  
  3. In article <1991Jul21.222926.12659@uunet.uu.net> brnstnd@KRAMDEN.ACF.NYU.EDU
  4. (Dan Bernstein) writes:
  5. >In article <1991Jul19.033239.8917@uunet.uu.net> Chuck Karish
  6. >(karish@mindcraft.com) writes:
  7. [ Dan Bernstein wrote: ]
  8. [ Secondary included text deleted for brevity's sake -- mod ]
  9. >My objection is to the idea of standardizing something which vendors
  10. >haven't even begun to look at. I feel the same way about sysconf() and
  11. >pathconf(), POSIX sessions (oh, right, HP-UX already had something like
  12. >this---how dare I argue against such a precedent?), and most of POSIX's
  13. >other inventions.
  14.  
  15. If you've been paying attention to this newsgroup, you know
  16. that POSIX sessions were invented because, when the working
  17. group tried to write a specification for job control, they
  18. discovered that the BSD behavior was underspecified and
  19. inconsistent.  They chose invention as the lesser of two
  20. evils rather than standardize on something that was wrong.
  21.  
  22. To elaborate on the security and efficiency issues, I fail to
  23. see that either getconf or /inst/bin has any impact on the
  24. administrator's ability to maintain reasonable system security.
  25. The directories and executables in the default path, including
  26. getconf, have to be protected no matter how many links there are
  27. to each file.  If it's possible for a bad guy to put a Trojan
  28. horse into the default path it doesn't matter whether its name
  29. is 'getconf' or 'login' or 'sh' or '/.profile' or '/etc/environment'.
  30.  
  31. As others have pointed out, the efficiency of using /inst/bin
  32. depends on the implementation.  I consider it to be a poor
  33. candidate for standardization.  If you want to use it on
  34. systems where it helps, go ahead.  Nothing in 1003.1 or 1003.2
  35. will break it.
  36.  
  37. >In this particular case, existing programs can be used with /inst/bin
  38. >without even changing the source code. All you have to do is change the
  39. >default system PATH. Adding getconf to a program means that the program
  40. >will no longer work on the vast majority of systems. That's what I mean
  41. >by unportable.
  42.  
  43. There's a simple fix that makes such scripts work:  install
  44. getconf.  It's easy to implement and no harder to install than
  45. patch or compress, which I regularly install on new systems in
  46. order to port other programs.  Scripts can be written to use
  47. getconf only if it exists, which allows them to be portable to
  48. non-POSIX.2 systems.
  49.  
  50. The issue of script portability is something of a red herring,
  51. because it has never been possible to write really portable
  52. scripts.  There's just too much variability in internal limits
  53. and return codes in utilities, which are formally standardized
  54. for the first time ("our implementation IS the standard",
  55. as AT&T is fond of saying, doesn't cut it) in POSIX.2.
  56.  
  57. getconf, sysconf(), pathconf() and fpathconf() exist to make it
  58. possible to allow programs to make full use of system
  59. capabilities without being re-compiled for differently-
  60. configured members of a binary-compatible family and without
  61. being crippled down to a lowest common denominator.  If
  62. you're happy to write code that works only on BSD systems,
  63. you're free to continue to do so.  Others who try to write
  64. portable programs can protect calls to pathconf(), sysconf(),
  65. etc. inside "#ifdef _POSIX_SOURCE" blocks and leave the
  66. traditional porting hackery to you, if that's what you want.
  67.  
  68. >> A puzzle for the reader (maybe this is obvious to everyone but
  69. >> me):  How can a shell script determine whether it's running on
  70. >> a POSIX.2 system?  If it calls getconf and getconf does not
  71. >> exist, the shell may exit.  It could call getconf in a
  72. >> subshell, but that's ugly and expensive.
  73. >
  74. >Congratulations. You just hit the nail right on the head.
  75.  
  76. There's a trivial fix for this, too: 1003.2 could require
  77. conforming systems or shells to pre-define an environment
  78. variable to indicate that POSIX.2 features are available.  Has
  79. this been considered?  If so, why was it rejected?
  80. -- 
  81.  
  82.     Chuck Karish        karish@mindcraft.com
  83.     Mindcraft, Inc.        (415) 323-9000
  84.  
  85. Volume-Number: Volume 24, Number 58
  86.  
  87.