randall@uvaarpa.Virginia.EDU (Randall Atkinson) (06/29/90)
From: randall@uvaarpa.Virginia.EDU (Randall Atkinson) I've recently received my copy of Draft 5 of the P1003.2a document and I've got some preliminary thoughts that I think might be worth mentioning generally. I want to be explicit in saying that I've only skimmed the document at this point and some of my concerns might in fact have been addressed in an area of the document that I haven't read closely. 1. I really want the standard to be meaningful in the areas that are specified. A specification that is too watered down and general isn't really useful. By way of example, the effect of the values chosen for POSIX2_MAX_NICE and POSIX2_MIN_NICE is to mean that a user can't depend on nice or renice doing anything to the job. The values chosen for those two contants should be different and have some meaningful (if limited) range to them so that a user can rely on the utilities having the same functionality as the existing utilities have. 2. In skimming the draft, there seem to be a number of places where there are implicit assumptions that western languages and character sets are being used. There appear at first glance to be several areas where support for Asian languages (for example written Chinese) is either non-existent or possibly impaired. This is an understandably difficult thing to specify carefully, particularly considering that there aren't many involved in the POSIX process who have familiarity with non-Western languages. 3. I support the general constraint of standardising existing practice rather than creating new extensions, but would much rather see more stringent requirements that utilities either send output to the controlling terminal or stdout. If this isn't specified, the existing practice of using piping and shell scripts on all of the UNIX \(tm shell utilities is potentially not supported. 4. Also, I would prefer to see output formats specified wherever possible, even if the output format might break some existing implementation which uses an incompatible output format. It is very difficult for anyone to safely predict in advance that some utility will never be used in a pipe or shell script or have its output processed by some other tool (e.g. awk) before being seen by a human. Hence, I tend to disagree with the paragraph on Page X from lines 166-179 where it states that "exactness of [output] format" has not been a primary concern. Standardisation of the output format is clearly within the scope of the present enterprise and enhances the usefulness of the resulting standard. Randall Atkinson randall@virginia.edu Volume-Number: Volume 20, Number 59