From hlj@posix Mon Apr 20 19:07:59 1992 Received: from netcomsv.netcom.com by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA22366; Mon, 20 Apr 92 19:07:59 +0200 Received: from posix.UUCP by netcomsv.netcom.com (4.1/SMI-4.1) id AA11143; Mon, 20 Apr 92 10:07:26 PDT Received: by posix.COM (smail2.5) id AA07577; 20 Apr 92 10:01:35 PDT (Mon) Subject: portability annex To: sc22wg15@dkuug.dk Date: Mon, 20 Apr 92 10:01:33 PDT From: Hal Jespersen Organization: POSIX Software Group, 447 Lakeview Way, Redwood City, CA 94062 Phone: +1 (415) 364-3410 FAX: +1 (415) 364-4498 X-Mailer: ELM [version 2.2 PL0] Message-Id: <9204201001.AA07573@posix.COM> X-Charset: ASCII X-Char-Esc: 29 This is the portability annex I referred to in the other email. Printed copies are in the P1003.2/D11.3 to be handed out in NZ. See you there. Hal --------- P1003.2/D11.3 Annex F (informative) Portability Considerations Editor's Note: A new informative annex for Draft 11.3. It is not 3 further diffmarked. The annex was added very late in balloting because 3 the TSG-1 recommendations just recently have been turned into 3 documentation requirements by JTC 1. This annex should be fully 3 developed by the time POSIX.2 is elevated to be an international 3 standard, which will correspond to the first revision of the IEEE 3 standard. 3 Since POSIX.2 and POSIX.2a now are advancing to approval on roughly the 3 same schedule, this annex has been written to address both documents at 3 once, without maintaining the separation that has characterized the 3 development of the ``base POSIX.2'' and its first amendment. Comments on 3 this annex are solicited from all balloting group members as well as 3 other interested parties, such as POSIX working group chairs and profile 3 writers who may cite POSIX.2 in future POSIX Standardized Profiles. 3 This annex contains information to satisfy the recommendations of the TSG-1 Final Report {B13} Annex A. The first clause describes perceived user requirements and the second indicates how the facilities of this standard satisfy those requirements. The third clause offers guidance to writers of profiles on how the configurable options, limits, and optional behavior of this standard should be cited in profiles. F.1 User Requirements This clause describes the user requirements that were perceived by the developers of this standard. The primary source for these requirements was an analysis of historical practice in widespread use, as typified by the Base Documents listed in the Introduction to this standard. The universe of users applicable to POSIX.2 is a superset of those addressed by POSIX.1 {9}:1) users requiring open systems solutions for Copyright (c) 1992 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 2 F Portability Considerations Part 2: SHELL AND UTILITIES P1003.2/D11.3 source-code portability of applications involving multiprogramming and process management (creating processes, signaling, etc.); access to files and directories in a hierarchy of file systems (opening, reading, writing, deleting files, etc.); access to asynchronous communications ports and other special devices; access to information about other users of the system. The users of POSIX.1 {9} are limited to those employing applications written in high-level languages, such as C, Ada, or Fortran. The following additional users are identified for POSIX.2: - Users who desire portable applications that do not necessarily require the characteristics of high-level languages (for example: the speed of execution of compiled languages or the relative security of source code intellectual property inherent in the compilation process). - Users who desire portable applications that can be developed quickly and can be modified readily without the use of compilers and other system components that may be unavailable on small systems or those without special application development capabilities. - Users who interact with a system to achieve general-purpose time sharing capabilities common to most business or government offices or academic environments: editing, filing, interuser communications, printing, etc. - Users who develop applications for POSIX.1 {9} or POSIX.2 systems. An acknowledged restriction on applicable users is that they are limited to the group of individuals who are familiar with the style of interaction characteristic of historically derived systems based on one of the UNIX operating systems (as opposed to other historical systems with different models, such as MS/DOS, Macintosh, VMS, MVS, etc.). Typical users would include program developers, engineers, or general purpose time-sharing users. The following subclauses list the perceived requirements for this universe of users, in addition to those identified by POSIX.1 {9}. __________ 1) POSIX.1 {9} presently has no comparable annex to this one, but one is expected in a future revision of that standard. Copyright (c) 1992 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. F.1 User Requirements 3 P1003.2/D11.3 INFORMATION TECHNOLOGY--POSIX F.1.1 Command Language Users should be able to define procedures that combine simple tools and/or applications into higher level components that perform to the specific needs of the user. The user should be able to store, recall, use, and modify these procedures. These procedures should employ a powerful command language that is used for recurring tasks in portable applications (scripts) in the same way that it is used interactively to accomplish one-time tasks. The language and the utilities that it uses must be consistent between systems to reduce errors and retraining. F.1.2 Interactive Facilities Use the system to accomplish individual tasks at an interactive terminal. The interface should be consistent, intuitive, and offer usability enhancements to increase the productivity of terminal users, reduce errors, and minimize retraining costs. Online documentation or usage assistance should be available. F.1.3 Accomplish Multiple Tasks Simultaneously Access applications and interactive facilities from a single terminal without requiring serial execution: switch between multiple interactive tasks; schedule one-time or periodic background work; display the status of all work in progress or scheduled; influence the priority scheduling of work, when authorized. F.1.4 Complex Data Manipulation Manipulate data in files in complex ways: sort, merge, compare, translate, edit, format, pattern match, select subsets (strings, columns, fields, rows, etc.). These facilities should be available to both portable applications and interactive users. F.1.5 File Hierarchy Manipulation Create, delete, move/rename, copy, backup/archive, and display files and directories. These facilities should be available to both portable applications and interactive users. Copyright (c) 1992 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 4 F Portability Considerations Part 2: SHELL AND UTILITIES P1003.2/D11.3 F.1.6 Locale Configuration Customize applications and interactive sessions for the cultural and language conventions of the user. Employ a wide variety of standard character encodings. These facilities should be available to both portable applications and interactive users. F.1.7 Interuser Communication Send messages or transfer files to other users on the same system or other systems on a network. These facilities should be available to both portable applications and interactive users. F.1.8 System Environment Display information about the status of the system (activities of users and their interactive and background work, file system utilization, system time, configuration and presence of optional facilities) and the environment of the user (terminal characteristics, etc.). Inform the system operator/administrator of problems. Control access to user files and other resources. F.1.9 Printing Output files on a variety of output device classes, accessing devices on local or network-connected systems. Control (or influence) the formatting, priority scheduling, and output distribution of work. These facilities should be available to both portable applications and interactive users. F.1.10 Software Development Develop (create and manage source files, compile/interpret, debug) portable open systems applications and package them for distribution to, and updating of, other systems. Copyright (c) 1992 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. F.1 User Requirements 5 P1003.2/D11.3 INFORMATION TECHNOLOGY--POSIX F.2 Portability Capabilities This clause describes the significant portability capabilities of this standard and indicates how the user requirements listed in F.1 are addressed. The capabilities are listed in the same format as the preceding user requirements; they are summarized in Table F-1. Table F-1 - POSIX.2 Portability Capability Summary _________________________________________________________________________ | Command Language | | Interactive Facilities | | Accomplish Multiple Tasks Simultaneously | | Complex Data Manipulation | | File Hierarchy Manipulation | | Locale Configuration | | Interuser Communication | | System Environment | | Printing | | Software Development | |________________________________________________________________________| F.2.1 Command Language The shell command language described in Section 3 is a common language useful in batch scripts, through an API to high-level languages [see 7.1 and for the C binding, system() and popen()], and through an interactive terminal (see the sh utility). The shell language has many of the characteristics of a high-level language, but has been designed to be more suitable for user terminal entry and includes interactive debugging facilities. Through the use of pipelining, many complex commands can be constructed from combinations of data filters and other common components. Shell scripts can be created, stored, recalled, and modified by the user with simple editors. In addition to the basic shell language, the following utilities offer features that simplify and enhance programmatic access to the utilities and provide features normally found only in high-level languages: basename, bc, command, dirname, echo, env, expr, false, printf, read, sleep, tee, test, time*,2) true, wait, xargs, and all of the special __________ 2) The utilities listed with an asterisk are present only on systems with the User Portability Utilities Option. There may be further restrictions on the utilities offered with various configuration Copyright (c) 1992 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 6 F Portability Considerations Part 2: SHELL AND UTILITIES P1003.2/D11.3 built-in utilities in 3.14. Unsatisfied_Requirements None. F.2.2 Interactive Facilities The utilities offer a common style of command-line interface through conformance to the Utility Syntax Guidelines (see 2.10.2) and the common utility defaults (2.11). The sh utility offers an interactive command- line history and editing facility. The following utilities in the User Portability Utilities Option have been customized for interactive use: alias, ex, fc, mailx, more, talk, vi, unalias, write; the man utility offers online access to system documentation. Unsatisfied_Requirements The command-line interface to individual utilities is as intuitive and consistent as historical practice allows. Work underway based on graphical user interfaces3) may be more suitable for novice or occasional users of the system. F.2.3 Accomplish Multiple Tasks Simultaneously The shell command language offers background processing through the asynchronous list command form; see 3.9.3.1. The nohup utility makes background processing more robust and usable. The kill utility can terminate background jobs. When the User Portability Utilities Option and the POSIX.1 {9} job control option are supported, the following utilities can support more complex background work: bg, fg, jobs. With just the User Portability Utilities Option, the following can support periodic job scheduling, control, and display: at, batch, crontab, nice, ps, renice. Unsatisfied_Requirements Terminals with multiple windows may be more suitable for some multitasking interactive uses than the job control approach in POSIX.2. See the preceding comments on graphical user interfaces. The nice and _________________________________________________________________________ option combinations; see the individual utility descriptions. 3) See Related Standards Activities in the Introduction. Copyright (c) 1992 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. F.2 Portability Capabilities 7 P1003.2/D11.3 INFORMATION TECHNOLOGY--POSIX renice utilities do not necessarily take advantage of complex system scheduling algorithms that are being developed by realtime standards efforts; additional facilities are expected in future revisions of POSIX.2. More sophisticated job processing facilities will be introduced in a future revision, based on work in supercomputing standards efforts. F.2.4 Complex Data Manipulation The following utilities address user requirements in this area: asa, awk, bc, cmp, comm, csplit*, cut, dd, diff, ed, ex*, expand*, expr, find, fold, grep, head, join, od, paste, pr, printf, sed, sort, split*, tabs*, tail, tr, unexpand*, uniq, uudecode*, uuencode*, wc. Unsatisfied_Requirements Sophisticated text formatting utilities, such as troff or TeX, are not included. Standards work in the area of SGML may satisfy this. F.2.5 File Hierarchy Manipulation The following utilities address user requirements in this area: basename, cat, cd, chgrp, chmod, chown, cksum, cp, dd, df*, diff, dirname, du*, find, ls, ln, mkdir, mkfifo, mv, patch*, pathchk, pax, pwd, rm, rmdir, test, touch. Unsatisfied_Requirements Some graphical user interfaces offer more intuitive file manager components that allow file manipulation through the movement of icons for novice users. F.2.6 Locale Configuration The standard utilities are affected by the various LC_ variables to achieve locale-dependent operation: character classification, collation sequences, regular expressions and shell pattern matching, date/time formats, numeric formatting, monetary formatting. When the {POSIX2_LOCALEDEF} option is supported, applications can provide their own locale definition files. The following utilities address user requirements in this area: date, ed, ex*, find, grep, locale, localedef, more*, sed, sh, sort, tr, uniq, vi*. Unsatisfied_Requirements Some aspects of multibyte-character and state-encoded character encodings have not yet been addressed. The C-language functions, such as getopt(), Copyright (c) 1992 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 8 F Portability Considerations Part 2: SHELL AND UTILITIES P1003.2/D11.3 are generally limited to single-byte characters. The affect of the LC_MESSAGES variable on message formats is only suggested at this time, and utilities for message catalog manipulation have not been defined. F.2.7 Interuser Communication The following utilities address user requirements in this area: cksum, mailx*, mesg*, patch*, pax, talk*, uudecode*, uuencode*, who*, write*. Unsatisfied_Requirements The historical UUCP utilities are not included. This type of requirement will be addressed as part of networking standards efforts. F.2.8 System Environment The following utilities address user requirements in this area: chgrp, chmod, chown, df*, du*, env, getconf, id, logger, logname, mesg*, newgrp*, ps*, stty, tput*, tty, umask, uname, who*. Unsatisfied_Requirements Considerable extra control of security, privilege, and auditing facilities will be added in a future revision, based on work underway in security standards efforts. F.2.9 Printing The following utilities address user requirements in this area: pr, lp. Unsatisfied_Requirements There are no features to control the formatting or scheduling of the print jobs. Such facilities will be added in a future revision, based on work underway in system administration standards efforts. F.2.10 Software Development The following utilities address user requirements in this area: ar, asa, awk, c89, ctags*, fort77, getconf, getopts, lex, localedef, make, nm*, od, patch*, pax, strings*, strip, time*, yacc. The functions in Annex B allow C-language programmers to access some of the interfaces used by the utilities, such as argument processing, regular expressions, and pattern matching. Copyright (c) 1992 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. F.2 Portability Capabilities 9 P1003.2/D11.3 INFORMATION TECHNOLOGY--POSIX Unsatisfied_Requirements There are no language-specific development tools related to languages other than C and Fortran. The C tools are more complete and varied than the Fortran tools. There is no source-code control system. There is no data dictionary or other CASE-like development tools. F.3 Profiling Considerations This clause offers guidance to writers of profiles on how the configurable options, limits, and optional behavior of this standard should be cited in profiles. Profile writers should consult the general guidance in POSIX.0 {B21} when writing POSIX Standardized Profiles. The information in this clause is an inclusive list of features that should be considered by profile writers. Further subsetting of this standard, including the specification of behavior currently described as unspecified, undefined, implementation defined, or with the verbs ``may'' or ``need not,'' violates the intent of the developers of this standard and the guidelines of TR 10000-1 {B12}. F.3.1 Configuration Options There are three broad optional configurations suggested by this standard: basic execution system, development system, and user portability interactive system. The options to support these, and other minor configuration options, are listed in 1.3.1.3. Profile writers should consult the following list and the comments concerning user requirements addressed by various POSIX.2 components in F.2. {POSIX2_UPE} The system supports the User Portability Utilities Option in Section 5. This option is a requirement for a user portability interactive system. It will be required frequently, except for those systems, such as embedded realtime or dedicated application systems, that support little or no interactive time sharing work by users or operators. {POSIX2_SW_DEV} The system supports the Software Development Utilities Option in Section 6. This option will be required by many systems, even those in which actual software development does not occur. The make Copyright (c) 1992 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 10 F Portability Considerations Part 2: SHELL AND UTILITIES P1003.2/D11.3 utility, in particular, will be required by many application software packages as they are installed onto the system. If {POSIX2_C_DEV} is supported, {POSIX2_SW_DEV} is almost a mandatory requirement, because of ar and make. {POSIX2_C_BIND} The system supports the C-Language Bindings Option in Annex B. This option will be required on some systems developing complex C applications or on any installing C applications in source form that require the functions. The system() and popen() functions, in particular, will be widely used by applications; the others are rather more specialized. {POSIX2_C_DEV} The system supports the C-Language Development Utilities Option in Annex A. This option will be required by many systems, even those in which actual C-language software development does not occur. The c89 utility, in particular, will be required by many application software packages as they are installed onto the system. The lex and yacc utilities will be used less frequently. {POSIX2_FORT_DEV} The system supports the FORTRAN Development Utilities Option in Annex C. As with C, this option is needed on any system developing or installing Fortran applications in source form. {POSIX2_FORT_RUN} The system supports the FORTRAN Runtime Utilities Option in Annex C. This option is required for some Fortran applications that need the asa utility to convert Hollerith printing statement output. It is unknown how frequently this will occur. {POSIX2_LOCALEDEF} The system supports the creation of locales as described in 4.35. This option is needed if applications require their own customized locale definitions to operate. It is presently unknown whether many applications will be dependent on this. However, the option is virtually mandatory for systems in which Copyright (c) 1992 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. F.3 Profiling Considerations 11 P1003.2/D11.3 INFORMATION TECHNOLOGY--POSIX internationalized applications are developed. {POSIX2_CHAR_TERM} The system supports at least one terminal type capable of all operations described in this standard. See 2.14. On systems with {POSIX2_UPE}, this option will almost always be required. It was developed solely to allow certain specialized vendors and user applications to bypass the requirement for general-purpose asynchronous terminal support. For example, an application and system that was suitable for block-mode terminals, such as IBM 3270s, would not need this option. F.3.2 Configurable Limits Very few of the limits in 2.13.1 will need to be increased for profiles. No profile can cite lower values. {POSIX2_BC_BASE_MAX} {POSIX2_BC_DIM_MAX} {POSIX2_BC_SCALE_MAX} {POSIX2_BC_STRING_MAX} No increase is anticipated for any of these bc values, except for very specialized applications involving huge numbers. {POSIX2_COLL_WEIGHTS_MAX} Some natural languages with complex collation requirements will require an increase from the default 2 to 4; no higher numbers are anticipated. {POSIX2_EXPR_NEST_MAX} No increase anticipated. {POSIX2_LINE_MAX} This number is much larger than most historical applications have been able to use. At some future time, applications may be rewritten to take advantage of even larger values, but this is unlikely at the present time. {POSIX2_RE_DUP_MAX} No increase anticipated. {POSIX2_VERSION} This is actually not a limit, but a standard version stamp. Generally, a profile should specify this standard by a name in the Normative References section, not this value. Copyright (c) 1992 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. 12 F Portability Considerations Part 2: SHELL AND UTILITIES P1003.2/D11.3 F.3.3 Optional Behavior In this standard, there are no instances of the terms unspecified, undefined, implementation defined, or with the verbs ``may'' or ``need not,'' that the developers of the standard anticipate or sanction as suitable for profile or test method citation. All of these are merely warnings to portable applications to steer clear of certain areas that can vary from system to system, and even over time on the same system. In many cases, these terms are used to explicitly allow for extensions, but profiles should not anticipate and require such extensions; future versions of the standard may do so. Copyright (c) 1992 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change. F.3 Profiling Considerations 13