home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v9 / text0017.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  3.2 KB
  1. From: pyramid!utzoo!henry (Henry Spencer)
  2. Date: Fri, 9 Jan 87 21:08:38 CST
  3.  
  4. > A general suggestion on the command groups:  provide just two sets.  A
  5. > mandatory group and a group that "if you have this function, you must
  6. > provide it under this name", a la X3.64.  No requirement that every
  7. > command in the optional group must be there if any of them are...
  8.  
  9. There is something to be said for this.  Unfortunately, there is also
  10. something to be said against it.  The problem is analogous to the one
  11. with X3.64, to wit that there is no "standard" beyond the basic one,
  12. or rather there are far too many, specifically 2**number_of_options.
  13. The result is that each system becomes unique, and the specification
  14. of what a particular application requires is no longer "P1003.2 with the
  15. optional command set" but "P1003.2 with A, B, C, D, E, F, G with the -x
  16. and -q options, H, I, and Q".  What this means in practice is that nobody
  17. bothers specifying exactly what his application needs, and the only way
  18. to find out whether it will work on your system is to try it (remembering,
  19. of course, to try out all features with all combinations of input data and
  20. all possible environments!).  It's better than no standard at all, but
  21. much less useful than a group that is a single option.
  22.  
  23. I would be interested to know why John thinks this is desirable.  The
  24. occasional situation of X being hard to do under system Y can be handled
  25. outside the standard ("we do all of P1003.2 except grep" :-)).
  26.  
  27. > I don't understand the philosophy that includes "cc" but excludes "as" and
  28. > is not sure about "lint" and "m4" and "strip".  I see a lot of makefiles
  29. > assuming all of these...
  30.  
  31. I would guess that the exclusion of "as" is because its behavior is utterly
  32. unportable even though its concept is not.  Why would a makefile for a
  33. fully portable program invoke "as", without at least making it conditional
  34. on a specific type of machine?  It's not clear to me that there is any
  35. portable operation that "as" can perform.  (Note that it is possible and
  36. plausible to have a compiler which does not generate assembler as an
  37. intermediate stage, so "assembling the results of a partial compile" is
  38. not a good answer.)
  39.  
  40. > I suggest that "cpio" be excluded.  Maybe they'll stop distributing
  41. > System V on byte-order-dependent cpio tapes if it becomes non-standard.
  42.  
  43. Agreed.  P1003.1 has already defined a standard interchange format, and it's
  44. not cpio (it is, in fact, a somewhat extended tar).
  45.  
  46. > There should be some way for shell scripts to invoke a pager...
  47.  
  48. If this is done (on the whole I like the idea), there should also be a way
  49. for the shell script to determine that it does not need to do so.  Many
  50. people feel that this function is best done in the terminal driver.  (My
  51. intent is not to re-open this debate in an inappropriate forum, but to
  52. point out that this is a subject on which there is no consensus and hence
  53. it would be better for 1003.2 not to take sides.)  Some existing programs
  54. honor the convention that a null (as opposed to missing) PAGER environment
  55. variable means "don't worry about it", but some do not.
  56.  
  57.                 Henry Spencer @ U of Toronto Zoology
  58.                 {allegra,ihnp4,decvax,pyramid}!utzoo!henry
  59.  
  60. Volume-Number: Volume 9, Number 18
  61.  
  62.