home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.20 / text0060.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  2.6 KB
  1. From:  randall@uvaarpa.Virginia.EDU (Randall Atkinson)
  2.  
  3. I've recently received my copy of Draft 5 of the P1003.2a document
  4. and I've got some preliminary thoughts that I think might be worth
  5. mentioning generally.  I want to be explicit in saying that I've
  6. only skimmed the document at this point and some of my concerns might
  7. in fact have been addressed in an area of the document that I haven't
  8. read closely.
  9.  
  10. 1.  I really want the standard to be meaningful in the areas that are
  11.   specified.  A specification that is too watered down and general isn't
  12.   really useful.  By way of example, the effect of the values chosen
  13.   for POSIX2_MAX_NICE and POSIX2_MIN_NICE is to mean that a user can't
  14.   depend on nice or renice doing anything to the job.  The values
  15.   chosen for those two contants should be different and have some
  16.   meaningful (if limited) range to them so that a user can rely on
  17.   the utilities having the same functionality as the existing utilities
  18.   have.
  19.  
  20. 2.  In skimming the draft, there seem to be a number of places where
  21.   there are implicit assumptions that western languages and character
  22.   sets are being used.  There appear at first glance to be several areas
  23.   where support for Asian languages (for example written Chinese) is
  24.   either non-existent or possibly impaired.  This is an understandably
  25.   difficult thing to specify carefully, particularly considering that
  26.   there aren't many involved in the POSIX process who have familiarity 
  27.   with non-Western languages.  
  28.  
  29. 3.      I support the general constraint of standardising existing
  30.   practice rather than creating new extensions, but would much rather
  31.   see more stringent requirements that utilities either send output to
  32.   the controlling terminal or stdout.  If this isn't specified, the 
  33.   existing practice of using piping and shell scripts on all of the
  34.   UNIX \(tm shell utilities is potentially not supported.  
  35.  
  36. 4.  Also, I would prefer to see output formats specified wherever possible,
  37.   even if the output format might break some existing implementation
  38.   which uses an incompatible output format.  It is very difficult for
  39.   anyone to safely predict in advance that some utility will never
  40.   be used in a pipe or shell script or have its output processed by
  41.   some other tool (e.g. awk) before being seen by a human.  Hence,
  42.   I tend to disagree with the paragraph on Page X from lines 166-179
  43.   where it states that "exactness of [output] format" has not been
  44.   a primary concern.  Standardisation of the output format is clearly
  45.   within the scope of the present enterprise and enhances the usefulness
  46.   of the resulting standard.
  47.  
  48.  
  49. Randall Atkinson
  50. randall@virginia.edu
  51.  
  52. Volume-Number: Volume 20, Number 59
  53.  
  54.