From: Hal Jespersen Organization: POSIX Software Group, 447 Lakeview Way, Redwood City, CA 94062 Phone: +1 (415) 364-3410 FAX: +1 (415) 364-4498 Hi. When I sent out the proposed Disposition of Comments for 9945-2, I neglected to send out the proposed revision to Annex H that would explain all the work that would be investigated for POSIX.2b. Here it is. I would appreciate any feedback on this separate from the letter ballot that Jim Isaak is sending out. Note the '|' diff marks of proposed changes. Hal Annex H (informative) Proposals for Future Revisions This informative annex describes modifications and enhancements that have been proposed for the next revision of this standard. Comments on this list and specific proposals are solicited; at the time of publication, not all of the items have initial proposals under consideration. See the introduction to this standard for information on participating in future work in these areas. The following clauses describe the five major areas of work currently authorized for the next revision of this standard. NOTE: As of this printing, this annex has been updated to account for | international comments on the balloting that advanced ISO/IEC DIS 9945- | 2:1992 to be the full International Standard, ISO/IEC 9945-2:1993. Other | comments from previous CD and DIS ballots are also included. The intent | of the IEEE P1003.2 working group and JTC1/SC22/WG15 is that these future | work areas be addressed as expeditiously as possible in the first | revision to IEEE Std 1003.2 and the first amendment to ISO/IEC 9945-2. | Development of this common revision and amendment is underway in the IEEE | as project P1003.2b. | H.1 Resolve International Comments to DIS 9945-2 There were a number of comments from SC22 member bodies that were deferred for consideration in the next revision. They are summarized here, in no specific order: (1) Provisions should be made to allow characters beyond those in the portable character set in user-supplied identifiers for the shell, awk, bc, lex, make, and yacc. A proposal has been made by Denmark to extend the locale definition to specify the set of identifier characters for all programming languages. (2) The shell, awk, other small languages, and regular expressions should be supported by national variants of ISO/IEC 646 {1}. A proposal from Denmark is expected in this area. (3) The LC_CTYPE (2.5.2.1) locale definition should be enhanced to allow user-specified additional character classes, similar in concept to the proposed C Standard {7} Multibyte Support Extension (MSE) is_wctype() function. (4) The LC_COLLATE (2.5.2.2) locale definition should be enhanced to allow user-specified names for collation weights. A proposal from Japan is expected in this area. (5) The collation substitute facility, removed from 2.5.2.2 in an early draft, should be restored. (6) A facility should be added to allow simple modifications to existing locale collation definitions. A proposal for such a replace_after keyword in LC_COLLATE is being developed by Denmark. (7) The specific encoding and collation requirements for the character NUL should be removed. (8) The support of state-dependent (shift encoding) character sets should be addressed fully. See descriptions of these in 2.4. If such character encodings are supported, it is expected that this will impact 2.4 (charmap), 2.5 (locale definition), 2.8 (regular expressions), and the comm, cut, diff, ex (list and | print commands), grep, head, join, paste, and tail utilities. A proposal from Japan is expected in this area. (9) The definition of column position (see 2.2.2.36) relies on the knowledge by the implementation of the integral width of the characters. The charmap (2.4) or LC_CTYPE (2.5.2.1) locale definitions should be enhanced to allow application specification of these widths. A proposal from Japan is expected in this area. (10) A utility (or feature of another utility, such as tr) should be provided that converts between character-set encodings based on two charmap files. A proposal from Denmark is expected in this area. (11) The date utility should allow width specifications for its fields, similar to those in the printf() function. (12) The file utility should allow user-specified algorithms for file type recognition, similar to those used in the historical /etc/magic file. (13) The pax utility should provide a new file interchange format, in addition to cpio and ustar, that allows extended characters in file, user, and group names. Rules should be given for the cases where an archived name cannot be represented by the local character set in the file system. NOTE: The example Danish Profile in Annex G contains a feature that implements a form of this proposal. It is not clear whether this is the solution that will be selected for the next revision. (14) The uuencode utility should support the BASE64-encoding specified in the MIME-RFC currently under consideration for Internet use. The uudecode utility should allow the user to override the output file name that is embedded in the file. Both utilities should be moved from Section 5 to Section 4. (15) The functions in Annex B that use the C-language char type should be modified to allow wide character (wchar_t) encodings, as suggested by the proposed MSE amendment to the C Standard {7}. A proposal from Japan is expected in this area. (16) The ls utility should be examined for a -k option, to parallel | the 1024 B usage in other utilities. | (17) Utilities using 1 s timer granularity should be studied for | requirements of improved resolution. | (18) The locale definition should allow the use of a form of ellipses | notation that would be independent of character set encoding. A | proposal for a ``symbolic ellipsis'' notation is being developed | by Denmark. | (19) The portions of the standard that are based on the User | Portability Utilities Option should be more clearly identified, | such as with parenthetical notations in subclause headers | outside of Section 5. | (20) Utilities, such as vi, that deal with units of text identified | as ``words'' (and ``bigwords'') are generally English-specific | and a mechanism should be included to allow specifications of | words in other locales. | (21) The effects of the combined use of the at -q b option and the | timespec operand should be specified. | (22) The title and description of the batch utility should be | reexamined for their appropriateness and accuracy. Specific | reference to ``execution in a batch queue'' should be included. | (23) The ex semantics for commands using the file operand (such as | edit and next) do not uniformly indicate that the characters % | and # are handled specially. All of the ex commands dealing | with file or directory names should be examined to determine if | they should be made uniform in this regard. In these commands, | the effect of re-editing a previously edited file on the current | line indicator should be made clear. | (24) The text of 5.10.7.2.37 should be reexamined to determine | whether the ex w >> or w! >> commands should parallel the | semantics of the comparable shell redirection operator for a | nonexisting file. | (25) The text of 5.10.7.4 should be reexamined to determine whether | the ex regular expression replacement \n symbol applies only to | the nth set of \( and \) earlier in the same RE string. | (26) The text of 5.10.7.5.9 should be reexamined for the clarity of | the description of the ex magic option. | (27) The more utility should be able to handle underlined and | emboldened displays of characters that are wider than a single | column position. | (28) The vi description of position exceptions (5.35.7.1) should be | expanded to deal with characters that are wider than a single | column position. | (29) The vi description of reversing character case (5.35.7.1.44) | should be expanded to deal with characters that have no | equivalents in the reverse case. | (30) The uses of the terms ``byte,'' ``character,'' ``coded character | set,'' ``glyph,'' ``graphic character,'' and ``graphic symbol,'' | should be aligned with such standards as ISO/IEC 646 {1}, ISO | 4873 {3}, and ISO/IEC 10367:1991. | (31) The POSIX special character names, such as , should | not be defined in 2.2.2, but in a special subclause for this | purpose. | H.2 Resolve Interpretation Requests and Correct Technical Defects Issues resulting from requests for interpretation (through either the IEEE or ISO/IEC processes) will be resolved. The clarity, accuracy, and precision of the language in this standard will be improved, correcting technical defects found in implementing systems, test suites, or applications based on this standard. Specific proposals are sought for this area. The following technical defects, or corrigenda, were identified during | international balloting on ISO/IEC 9945-2:1993. | (1) In 2.2.2.94, the definition of job control job ID, the precise | syntax of the IDs including the string token is unclear. | (2) The final paragraph of 2.4.1 implies that there are special | interpretations of the dollar sign and number sign characters | described in 2.2.2, but no text appears in 2.2.2.45 or 2.2.2.110 | to explain these interpretations. | (3) Table 2-9, listing the LC_MONETARY Category Definition in the | POSIX Locale, omits the value to be assigned to frac_digits. | (4) In the first paragraph of 2.5.2.3, the meaning of the phrase | ``is not available in the locale'' is not defined precisely. | (5) Table 2-11, listing the LC_TIME Category Definition in the POSIX | Locale, contains the following entry: | # Appropriate 12 h time representation (%r) "%I:%M:%S %p" | t_fmt_ampm "\ |

" | It in unclear whether there is a space between and | (which should have been represented as to | match the other entries) or whether this is a typographical | error. | (6) In the 4.40.5.3 description of the mailx LISTER variable, the | sentence ``The default value shall be unset'' may be redundant. | (7) In 4.40.7.2.11, the mailx folders command does not indicate how | the value of the LISTER variable affects this command. | (8) In 5.2, the at utility description is confusing because the same | symbol time is used for two different values: the -t time | option-argument and one of the timespec fields. | (9) In 5.2.6.2, the at message | "job %s at %s\n", at_job_id, | is in English, but there is no indication of whether it is | dependent on the POSIX Locale. | (10) In 5.10.7.2.1 and 5.10.7.2.14, the precise syntax of the ex | abbrev and map rhs tokens is unclear. | (11) In 5.10.7.2.47, the synopses for @ and * do not indicate that | the buffer argument is optional, contradicting the following | text. | (12) In the second paragraph of 5.10.7.4, the phrase ``(using the \& | or \)'' does not address the two modes (magic and | nomagic) that affect the use of & in ex replacement strings. | (13) In 5.10.7.5.20, the unit of width for the ex shiftwidth option | is not indicated. | (14) In 5.10.7.5.23, the unit of width for the ex tabstop option is | not indicated. | (15) In 5.11.5.3 and 5.32.5.3, in the last sentence of the LC_CTYPE | paragraph for expand and unexpand, the phrase ``on a constant- | width-font output device'' may be redundant because of | definitions elsewhere in the standard. | (16) In 5.26.3, the description of -n number does not clearly | indicate the unit for measuring the minimum string length. | (17) In 5.35.7.1.12, the vi control-T description, it is unclear | whether the term ``space characters'' is equivalent to `` | characters.'' | (18) In 5.35.7.1.32, the vi | description, it is unclear whether the | term ``wide character'' is equivalent to ``multicolumn | character.'' | H.3 Revise Granularity of Options Some of the groups producing functional standards (profiles) based on POSIX.2 desire finer granularity in groupings of optional utilities and features. For example, the 72 utilities in Section 4 may be too many for some profiles to require. Specific proposals are sought for this area. H.4 Support Features of 9945-1 Revision There is a desire to incorporate interfaces associated with new facilities being produced for the next revision of POSIX.1 {8} (POSIX.1a), such as symbolic links. NOTE: Extended or supplementary shell and utility features based on POSIX.1a interfaces will be included as normative parts of POSIX.2 only if schedules can be arranged so that the POSIX.1a supplement is available for citation as a normative reference at the time of approval of the next revision of this standard. H.5 Reorganize 9945-1 and 9945-2 Material The Document Structure Plan for the ISO/IEC 9945 standards has proposed a reorganization of material between 9945-1 and 9945-2. The following changes are being considered, assuming that mutually acceptable approval schedules are possible (i.e., these sections will be removed from future revisions of POSIX.2 only when other approved POSIX standards have incorporated them): (1) Move the cpio and ustar file format descriptions from 9945-1 Section 10 to the 9945-2 pax utility. (2) Remove 9945-2 Section 7 and move the APIs [system(), regcomp(), etc.] from Annex B to the language-independent version of 9945-1 and its corresponding language-binding standards. (3) Move the language-dependent development utilities in Annexes A and C to other standards related to those programming languages.