IEEE P1003.2a Draft 8 - December 1991 Copyright (c) 1991 by the Institute of Electrical and Electronics Engineers, Inc. 345 East 47th Street New York, NY 10017, USA All rights reserved as an unpublished work. This is an unapproved and unpublished IEEE Standards Draft, subject to change. The publication, distribution, or copying of this draft, as well as all derivative works based on this draft, is expressly prohibited except as set forth below. Permission is hereby granted for IEEE Standards Committee participants to reproduce this document for purposes of IEEE standardization activities only, and subject to the restrictions contained herein. Permission is hereby also granted for member bodies and technical committees of ISO and IEC to reproduce this document for purposes of developing a national position, subject to the restrictions contained herein. Permission is hereby also granted to the preceding entities to make limited copies of this document in an electronic form only for the stated activities. The following restrictions apply to reproducing or transmitting the document in any form: 1) all copies or portions thereof must identify the document's IEEE project number and draft number, and must be accompanied by this entire notice in a prominent location; 2) no portion of this document may be redistributed in any modified or abridged form without the prior approval of the IEEE Standards Department. Other entities seeking permission to reproduce this document, or any portion thereof, for standardization or other activities, must contact the IEEE Standards Department for the appropriate license. Use of information contained in this unapproved draft is at your own risk. IEEE Standards Department Copyright and Permissions 445 Hoes Lane, P.O. Box 1331 Piscataway, NJ 08855-1331, USA +1 (908) 562-3800 +1 (908) 562-1571 [FAX] P1003.2a/D8 INFORMATION TECHNOLOGY--POSIX 2.14 Terminal Characteristics => 2.14 Terminal Characteristics. _A_d_d _a _n_e_w _c_l_a_u_s_e _2._1_4: This clause applies only to systems supporting the User Portability 7 Utilities Option. 7 The standard utilities historically have been implemented on a wide range of terminal types, but a conforming implementation need not support all features of all utilities on every conceivable terminal. This standard states which features are optional for certain classes of terminals in the individual utility description clauses. The implementation shall document which terminal types it supports and which of these features and utilities are not supported by each terminal. This implementation- defined list of terminals: - Shall include at least one terminal type that is capable of supporting all of the standard utilities and all of their features, if the {POSIX2_CHAR_TERM} option is provided. - May group terminals in terms of families or equivalences to other documented terminal types. - Need not consist of an exhaustive list of terminal models when the implementor considers that some terminal types are used too infrequently to be listed. When a feature or utility is not supported on a specific terminal type, as allowed by this standard, and the implementation considers such a condition to be an error preventing use of the feature or utility, the implementation shall indicate such conditions through diagnostic messages or exit status values or both (as appropriate to the specific utility description) that inform the user that the terminal type lacks the appropriate capability. This standard uses a notational convention based on historical practice that identifies some of the control characters defined in 2.4 in a manner easily remembered by users on many terminals. The correspondence between this ``control- _c_h_a_r'' notation and the actual control characters is shown in Table 2-101. When this standard refers to a character by its control- name, it is referring to the actual control character shown in the Value column of the table, which is not necessarily the exact control key sequence on all terminals. Some terminals have keyboards that do not allow the direct transmission of all the nonalphanumeric characters shown. In such cases, the system documentation shall describe which data sequences transmitted by the terminal shall be interpreted by the system as representing the special characters. NOTE: The notation uses uppercase letters for arbitrary editorial Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 16 2 Revisions to Terminology and General Requirements PART 2: SHELL AND UTILITIES -- Amd. 1: UPE P1003.2a/D8 Table 2-101 - Control Character Names __________________________________________________________________________________________________________________________________________________ Name Value Name Value Name Value ________________________________________________________________________ control-A control-L control-W control-B control-M control-X control-C control-N control-Y control-D control-O control-Z control-E control-P control-[ control-F control-Q control-\ control-G control-R control-] control-H control-S control-^ control-I control-T control-_ control-J control-U control-? control-K control-V __________________________________________________________________________________________________________________________________________________ reasons. There is no implication that the keystrokes represent control- shift-letter sequences. BEGIN_RATIONALE _T_e_r_m_i_n_a_l _C_h_a_r_a_c_t_e_r_i_s_t_i_c_s _R_a_t_i_o_n_a_l_e. (_T_h_i_s _s_u_b_c_l_a_u_s_e _i_s _n_o_t _a _p_a_r_t _o_f _P_1_0_0_3._2_a) There are at least two types of terminals that might have difficulty with certain utility features: hard copy terminals and block-mode terminals. It is the intention of the developers of this standard that the list of supported terminals and features be presented as tersely as the implementors may desire. Subsets of terminal types may be included, based upon marketing requirements. Generous use of correct global statements is preferable to itemized lists of features for each of hundreds of terminal types. Attention should be directed to clarifying nonsupported features on terminal types that would otherwise be expected to support such features, due to those terminals' similarity to documented types. It is the intention of the developers of this standard that when a terminal cannot support a certain feature, the utility should produce a useful diagnostic status or message explicitly informing the user of this fact. It should not produce a syntax error, ``unknown command,'' or ``unknown feature'' message or status. (This intent is not in the normative text because it is difficult to describe except with examples.) Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 2.14 Terminal Characteristics 17 P1003.2a/D8 INFORMATION TECHNOLOGY--POSIX Terminals that do not have the ability to send some of the special characters are in wide industry use, although not on the historical systems that form the basis for this standard. For example, the 3270 family of mainframe synchronous terminals cannot directly send the control characters. Therefore, implementations have to document how to do so; it could be by using a series of keystrokes, or by special function keys. In the 3270 example, PF3 has been used as a control-D equivalent. The {POSIX2_CHAR_TERM} option was added to allow a vendor supporting only block-mode terminals to still conform, even though some utilities, such as vi, have limited usefulness. The vi editor is the only utility in POSIX.2 that can be entirely omitted if this option is not supported; others, such as ex, more, and talk, still have useful feature subsets that are unrelated to the terminal variety. The decision on whether to require conformance to {POSIX2_CHAR_TERM} is strictly one of marketing. Even when this option is provided, however, there is no guarantee that _e_v_e_r_y terminal on the system will support all features; the option implies that the software drivers and other support features are installed, but not that any of the terminals were actually hooked up. END_RATIONALE Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 18 2 Revisions to Terminology and General Requirements P1003.2a/D8 Section 3: Revisions to Shell Command Language => 3.1 Shell Definitions. _M_o_d_i_f_y _t_h_e _c_o_n_t_e_n_t_s _o_f _c_l_a_u_s_e _3._1, _S_h_e_l_l _D_e_f_i_n_i_t_i_o_n_s, _t_o _a_d_d _t_h_e _f_o_l_l_o_w_i_n_g _d_e_f_i_n_i_t_i_o_n _i_n _t_h_e _c_o_r_r_e_c_t _s_o_r_t_e_d _o_r_d_e_r [_d_i_s_r_e_g_a_r_d_i_n_g _t_h_e _s_u_b_c_l_a_u_s_e _n_u_m_b_e_r _s_h_o_w_n _h_e_r_e]. 3.1 Shell Definitions 3.1.101 alias name: A word consisting solely of underscores, digits, and alphabetics from the portable character set (see 2.4) and any of the following characters: ! % , @ 7 Implementations may allow other characters within alias names as an 7 extension. 7 BEGIN_RATIONALE 7 _R_a_t_i_o_n_a_l_e_.__(_T_h_i_s__s_u_b_c_l_a_u_s_e__i_s__n_o_t__a__p_a_r_t__o_f__P_1_0_0_3_._2_a_) The characters allowed in alias names are from historical practice. END_RATIONALE => 3.3.1 Alias Substitution. _M_o_d_i_f_y _t_h_e _c_o_n_t_e_n_t_s _o_f _c_l_a_u_s_e _3._3, _T_o_k_e_n _R_e_c_o_g_n_i_t_i_o_n, _t_o _a_d_d _t_h_e _f_o_l_l_o_w_i_n_g _s_u_b_c_l_a_u_s_e: 3.3.1 Alias Substitution The processing of aliases shall be supported if the system supports the User Portability Utilities Option. Copyright (c) 1991 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 3.1 Shell Definitions 19