ISO/IEC 14515-2:2003

INTERNATIONAL ISO/IEC
STANDARD 14515-2
IEEE
Std 2003.2-1996
First edition
2003-09-01
Information technology — Portable ®
Operating System Interface (POSIX ) —
Test methods for measuring
conformance to POSIX —
Part 2:
Shell and utilities
Technologies de l'information — Interface de système de ®
fonctionnement portable (POSIX ) — Méthodes d'essai pour mesurer
la conformité au POSIX —
Partie 2: Enveloppe et utilités

Reference number
IEEE
Std 2003.2-1996 Edition
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
ISO
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.ch
Web www.iso.ch
IEEE Std 2003.2-1996
Information Technology —
Test Methods for Measuring Conformance to

POSIX — Part 2: Shell and Utilities
Sponsor
Portable Application Standards Committee
of the
IEEE Computer Society
Approved 20 June 1996
IEEE Standards Board
International Organization for Standardization/International Electrotechnical Commission
Case postale 56 • CH-1211 Genève 20 • Switzerland


Abstract: A definition of the requirements placed upon providers of a POSIX
Conformance Test Suite for the POSIX.2 standard (ISO/IEC 9945-2:1993,
IEEE/ANSI Std. 1003.2-1992) is provided. These requirements consist of a list of
assertions defining those aspects of POSIX.2 that are to be tested and the associ-
ated test methods that are to be used in performing those tests. This standard is
primarily aimed at test suite providers but it also defines to POSIX.2 implementors
those aspects of the standard that will be verified by a conformance test suite.
Keywords: conformance, POSIX, Shell and Utilities, test methods
The Institute of Electrical and Electronics Engineers, Inc.
3 Park Avenue, New York, NY 10016-5997, USA
All rights reserved. Published 1 September 2003. Printed in the United States of America.
Print: ISBN 0-7381-3800-2 SH95167
PDF: ISBN 0-7381-3801-0 SS95167
No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior
written permission of the publisher.

International Standard ISO/IEC 14515-2:2003(E)
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this part of ISO/IEC 14515 may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
International Standard ISO/IEC 14515-2 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information
technology, Subcommittee SC 22, Programming languages, their environments and system software interfaces.
ISO/IEC 14515 consists of the following parts, under the general title Information technology — Portable Operating ®
System Interface (POSIX  ) — Test methods for measuring conformance to POSIX:
� Part 1: System interfaces
� Part 2: Shell and utilities
Annexes A, B and C form a normative part of this part of ISO/IEC 14515. Annex D is for information only.
International Organization forSta ndardization/International Electrotechnical Commission
Case postale 56 � CH-1211 Genève 20 � Switzerland

IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the
IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a consensus
development process, approved by the American National Standards Institute, which brings together volunteers
representing varied viewpoints and interests to achieve the final product. Volunteers are not necessarily members of the
Institute and serve without compensation. While the IEEE administers the process and establishes rules to promote fairness
in the consensus development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of the
information contained in its standards.
Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property or other
damage, of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting
from the publication, use of, or reliance upon this, or any other IEEE Standard document.
The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly disclaims
any express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or that
the use of the material contained herein is free from patent infringement. IEEE Standards documents are supplied “AS IS.”
The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market,
or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the
time a standard is approved and issued is subject to change brought about through developments in the state of the art and
comments received from users of the standard. Every IEEE Standard is subjected to review at least every five years for
revision or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is reasonable to
conclude that its contents, although still of some value, do not wholly reflect the present state of the art. Users are cautioned
to check to determine that they have the latest edition of any IEEE Standard.
In publishing and making this document available, the IEEE is not suggesting or rendering professional or other services
for, or on behalf of, any person or entity. Nor is the IEEE undertaking to perform any duty owed by any other person or
entity to another. Any person utilizing this, and any other IEEE Standards document, should rely upon the advice of a
competent professional in determining the exercise of reasonable care in any given circumstances.
Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific
applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare
appropriate responses. Since IEEE Standards represent a consensus of concerned interests, it is important to ensure that any
interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its
societies and Standards Coordinating Committees are not able to provide an instant response to interpretation requests
except in those cases where the matter has previously received formal consideration.
Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with
IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate
supporting comments. Comments on standards and requests for interpretations should be addressed to:
Secretary, IEEE-SA Standards Board
445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855-1331
USA
Note: Attention is called to the possibility that implementation of this standard may require use of subject
matter covered by patent rights. By publication of this standard, no position is taken with respect to the
existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for
identifying patents for which a license may be required by an IEEE standard or for conducting inquiries into the
legal validity or scope of those patents that are brought to its attention.
Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute of
Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To
arrange for payment of licensing fee, please contact Copyright Clearance Center, Customer Service, 222 Rosewood Drive,
Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for educational
classroom use can also be obtained through the Copyright Clearance Center.

Introduction
(This introduction is not a normative part of IEEE Std 1003.2-1996, IEEE Standard for Information

Technology — Test Methods for Measuring Conformance to POSIX — Part 2: Shell and Utilities
Interfaces, but is included for information only.)
The primary purpose of this standard is to define test methods for POSIX.2 {9}. It
is intended for systems implementors and verification software developers. It is
complementary to POSIX.2 {9} (second in a family of ‘‘POSIX’’ standards), which
specifies a standard interface and environment for application programs that
require the services of a ‘‘shell’’ command language interpreter and a set of com-
mon utility programs. (See 1.1 for a full description of the relationship between
the standards.)
The majority of this standard describes the assertions that a test suite shall pro-
vide for the execution of a conformance test for the POSIX.2 {9} standard. The
standard also describes the various other test methods that are to be used in the
development or execution of such a test suite, and it describes the complimentary
procedures that are needed to assess the results of the execution of the test suite.
This standard should be read in conjunction with ISO/IEC 13210:1994 (ANSI/IEEE
Std 1003.3-1991) Standard for Information Technology — Test Methods for
Measuring Conformance to POSIX {11}, which defines the general test method
requirements applicable to POSIX Conformance Testing.
Organization of This Standard
The standard is divided into nine parts:
— General, including a statement of scope, normative references, a description
of test suite conformance requirements, and a description of the test
methods specific to POSIX.2 {9} testing (Section 1).
— Assertions for definitions, general requirements, and the environment
available to applications (Section 2).
— Assertions for the shell command language interpreter (Section 3).
— Assertions for the utilities in the required ‘‘Execution Environment Utili-
ties’’ (Section 4).
— Assertions for the utilities in the optional ‘‘User Portability Utilities’’ (Sec-
tion 5).
— Assertions for the utilities in the optional ‘‘Software Development Utilities’’
(Section 6).
— Assertions for the utilities in the optional ‘‘C Language Development Utili-
ties’’ (Annex A).
— Assertions for C Language Bindings option (Annex B).
— Assertions for the utilities in the optional ‘‘FORTRAN Development and
Runtime Utilities’’ (Annex C).
iii
This introduction, any footnotes, notes accompanying the text, and the informa-
tive annexes are not considered part of the standard. Annexes A through C are
normative and the other annexes are informative.
Acknowledgments
We wish to thank the following organizations for donating significant computer,
printing, and editing resources to the production of this standard: McCarron
Advanced Computing Services, Inc., The POSIX Software Group, UniSoft Limited,
and The Open Group.
Also we wish to thank the organizations employing the members of the working
group and the balloting group for both covering the expenses related to attending
and participating in meetings, and for donating the time required both in and out
of meetings for this effort.
Related Standards Activities
Activities to extend this standard to address additional requirements are in pro-
gress, and similar efforts can be anticipated in the future.
The following areas are under active consideration at this time or are expected to
1)
become active in the near future:
(1) Language-independent service descriptions of POSIX.1 {8}
(2) C, Ada, and FORTRAN language bindings to (1)
(3) Verification testing methods
(4) Realtime facilities
(5) Secure/Trusted system considerations
(6) Network interface facilities
(7) System administration
(8) Graphical user interfaces
(9) Profiles describing application- or user-specific combinations of open sys-
tems standards for: supercomputing, multiprocessor, and batch exten-
sions; transaction processing; realtime systems; and multiuser systems
based on historical models
(10) An overall guide to POSIX-based or related open systems standards and
profiles
Extensions are approved as ‘‘amendments’’ or ‘‘revisions’’ to this document, follow-
ing IEEE and ISO/IEC procedures.
Approved amendments are published separately until the full document is
reprinted and such amendments are incorporated in their proper positions.
________________
1) A Standards Status Report that lists all current IEEE Computer Society standards projects is
available from the IEEE Computer Society, 1730 Massachusetts Avenue NW, Washington, DC
20036-1903; Telephone: +1 202 371-0101; FAX: +1 202 728-9614.
iv
If you have an interest in participating in the Portable Applications Standards
Committee (PASC) working groups addressing these issues, please send your
name, address, and phone number to the Secretary, IEEE Standards Board, Insti-
tute of Electrical and Electronics Engineers, Inc., P.O. Box 1331, 445 Hoes Lane,
Piscataway, NJ 08855-1331, and ask to have this forwarded to the chair of the
appropriate PASC working group. If you have an interest in participating in this
work at the international level, contact your ISO/IEC national body.
IEEE Std 2003.2-1996 was prepared by the P2003.2 Working Group, sponsored by
the Portable Applications Standards Committee of the IEEE Computer Society. At
the time this standard was approved, the membership of the P2003.2 Working
Group was as follows:
Portable Applications Standards Committee (PASC)
Chair: Lowell Johnson
Vice Chair: Charles Severance
Functional Chairs: Jay Ashford
Andrew Josey
Barry Needham
Stephe Walli
Secretary: Nicholas Stoughton
P2003.2 Working Group Officials
Chair: Lowell Johnson
Vice Chair: Krystyne Supplee
Editor: Andrew Twigger
Secretary: Steve Henderson
Working Group
Sanjay Agraharam Yvonne Gee Gerald Powell
Lynda Allen Dave Grindeland Bill Putman
Helene Armitage Ken Harvey Vella Raman
John Bissell Barry Hedquist Elliot Rappaport
Barry Books Gail Holmes John Reed
Keith Bostic Eric Horner David Rowley
Gary Bradley Hal Jespersen Piyanai Saowarattitada
Mark Brown Greg Jones Tom Shem
Dawn Burnett David Korn Keith Stobie
Suzanne Callaghan Mark Lamonds William Sudman
Kate Chen Chuck Lanchester Scott Sutter
Steven Church Eric Lewine Ravi Tavakley
Anthony Cincotta Roger Martin William Toth
Don Cragun Eric Matsono Sandy Waters
Patric Dempster James Moe Bruce Weiner
Kevin Dodson Cindy Morris N. Ray Wilkes
Stan Douglas Anita Mundkur David Williams
Shiela Frankel Arnie Powell Fred Zlotnick
v
The following persons were members of the balloting group:
Nick Stoughton EurOpen Institutional Representative
Robert Boucher Uniforum Institutional Representative
Lynda Allen Barry Hedquist A. W. Powell
Ralph Barker John L. Hill Piyanai Saowarattitada
Andy R. Bihain Richard Hughes-Rowlands Keith Stobie
Robert Bismuth Hal Jespersen Krystyne Supplee
Michael E. Browne Lowell Johnson James G. Tanner
Dawn Burnett Judy Kerner Ravi Tavakley
Suzanne Callaghan Alan W. Kiecker Donn S. Terry
Stephan M. Chan Thomas M. Kurihara Andrew T. Twigger
William Cox Greger Leijonhufvud Mark-Rene Uchida
Donald Cragun Kevin Lewis Stephen R. Walli
Fred D. Crowner Roger Martin Bruce Weiner
Dave Decot Roland McGrath Andrew E. Wheeler
Stephen L. Diamond Pete Meier Alex White
Stanford Douglas Mark Modig Peter Wishart
Sheila Frankel John S. Morris Oren Yuen
Michel Gien Landon Curt Noll George R. Zerdian
Dave Grindeland
When the IEEE Standards Board approved this standard on 20 June 1996, it had
the following membership:
Donald C. Loughry, Chair Richard J. Holleman, Vice Chair
Andrew G. Salem, Secretary
Gilles A. Baril E. G. ‘‘Al’’ Kiener Arthur K. Reilly
Clyde R. Camp Joseph L. Koepfinger∗Ronald H. Reimer
Joseph A. Cannatelli Stephen R. Lambert Gary S. Robinson
Stephen L. Diamond Lawrence V. McCall Ingo Rsch
Harold E. Epstein L. Bruce McClung John S. Ryan
Donald C. Fleckenstein Marco W. Migliaro Chee Kiow Tan
Jay Forster∗Mary Lou Padgett Leonard L. Tripp
Donald N. Heirman John W. Pope Howard L. Wolfman
Ben C. Johnson Jose R. Ramos
∗Member Emeritus
Also included are the following nonvoting IEEE Standards Board liaisons:
Satish K. Aggarwal Alan H. Cookson Chester C. Taylor
Trademarks

POSIX is a registered certification mark of the Institute of Electrical and Elec-
tronics Engineers, Inc.

UNIX is a registered trademark in the United States and other countries,
licensed exclusively through X/Open Company Limited.

X/Open is a registered trademark and the ‘‘X’’ device is a trademark of X/Open
Company Limited.
vi
Contents
PAGE
Introduction .
iii
Section 1: General . 1
1.1 Scope . 1
1.2 Normative References . 1
1.3 Conformance . 3
Section 2: Conformance, Terminology, and General Requirements . 5
2.1 Conventions. 5
2.2 Definitions . 9
2.3 POSIX.2 {9} Conformance, Definitions and Built-in Utilities . 11
2.4 Character Set . 15
2.5 Locale. 17
2.6 Environment Variables . 46
2.7 Required Files . 48
2.8 Regular Expression Notation . 48
2.9 Dependencies on Other Standards . 74
2.10 Utility Conventions . 77
2.11 Utility Description Defaults . 78
2.12 File Format Notation . 82
2.13 Configuration Values. 82
2.14 Terminal Characteristics . 82
Section 3: Shell Command Language . 85
3.1 Shell Introduction . 85
3.2 Quoting . 85
3.3 Token Recognition . 87
3.4 Reserved Words . 89
3.5 Parameters and Variables . 90
3.6 Word Expansions . 92
3.7 Redirection . 114
3.8 Exit Status and Errors . 119
3.9 Shell Commands . 121
3.10 Shell Grammar . 127
3.11 Signals and Error Handling . 128
3.12 Shell Execution Environment. 128
3.13 Special Built-in Commands . 135
Section 4: Execution Environment Utilities . 147
4.1 awk — Pattern scanning and processing language. 147
4.2 basename — return nondirectory portion of pathname . 203
4.3 bc — Arbitrary-precision arithmetic language . 207
4.4 cat — Concatenate and print files . 221
4.5 cd — Change working directory . 225
vii
4.6 chgrp — Change file group ownership . 229
4.7 chmod — Change file modes . 234
4.8 chown — Change file ownership . 242
4.9 cksum — Display file checksums and block counts . 247
4.10 cmp — Compare two files . 251
4.11 comm — select or reject lines common to two files . 256
4.12 command — Execute a simple command . 262
4.13 cp — Copy files . 268
4.14 cut — Cut out selected fields of each line of a file . 281
4.15 date — Display the date and time . 287
4.16 dd — Convert and copy a file . 295
4.17 diff — Compare two files. 303
4.18 dirname — Return directory portion of pathname . 311
4.19 echo — Write arguments to standard output . 315
4.20 ed — Text editor . 317
4.21 env — Set environment for command execution . 375
4.22 expr — Evaluate arguments as an expression . 379
4.23 false — Return false value . 391
4.24 find — Find files. 393
4.25 fold — Filter for folding lines . 414
4.26 getconf — Get POSIX configuration values. 420
4.27 getopts — Parse utility options . 429
4.28 grep — File pattern searcher . 435
4.29 head — Copy the first part of files . 463
4.30 id — Return user identity. 467
4.31 join — Relational database operator . 474
4.32 kill — Terminate or signal processes . 484
4.33 ln — Link files . 488
4.34 locale — Get locale-specific information . 495
4.35 localedef — Get locale-specific information . 499
4.36 logger — Log messages . 508
4.37 logname — Return user’s login name . 511
4.38 lp — Send files to a printer . 513
4.39 ls — List directory contents . 518
4.40 mailx — Interactive message processing system. . 530
4.41 mkdir — Make directories. 598
4.42 mkfifo — Make FIFO special files . 605
4.43 mv — Move files . 612
4.44 nohup — Invoke a utility immune to hangups . 623
4.45 od — Dump files in various formats . 627
4.46 paste — Merge corresponding or subsequent lines of files . 636
4.47 pathchk — Check pathnames . 641
4.48 pax — Portable archive interchange . 646
4.49 pr — Print files . 672
4.50 printf — Write formatted output . 679
4.51 pwd — Return working directory name . 687
4.52 read — Read a line from standard input . 689
4.53 rm — Remove directory entries . 693
4.54 rmdir — Remove directories . 699
4.55 sed — Stream editor . 704
4.56 sh — Shell, the standard command language interpreter . 728
4.57 sleep — Suspend execution for an interval . 758
viii
4.58 sort — Sort, merge or sequence check text files . 760
4.59 stty — Set the options for a terminal. 770
4.60 tail — Copy the last part of a file . 778
4.61 tee — Duplicate standard input. 785
4.62 test — Condition evaluation utility . 790
4.63 touch — Change file access and modification times . 798
4.64 tr — Translate Characters . 806
4.65 true — Return true value. 811
4.66 tty — Return user’s terminal name . 813
4.67 umask — Get or set file mode creation mask . 816
4.68 uname — Return system name . 820
4.69 uniq — Report or filter out repeated lines in a file . 824
4.70 wait — Await process completion . 831
4.71 wc — Word, line, and byte count . 835
4.72 xargs — Construct argument list(s) and execute utility . 839
Section 5: User Portability Utilities Option . 847
5.1 alias — Define or display attributes . 847
5.2 at — Execute commands at a later time . 851
5.3 batch — Execute commands when the system load permits . 861
5.4 bg — Run jobs in background. 864
5.5 crontab — Schedule periodic background work . 869
5.6 csplit — Split files based on context . 875
5.7 ctags — Create a tags file . 883
5.8 df — Report free disk space . 891
5.9 du — Estimate file space usage . 896
5.10 ex — Text editor . 901
5.11 expand — Convert tabs to spaces . 979
5.12 fc — Process command history list. 985
5.13 fg — Run jobs in the foreground . 992
5.14 file — Determine file type . 996
5.15 jobs — Display status of jobs in the current session . 1002
5.16 man — Display system documentation . 1008
5.17 mesg — Permit or deny messages . 1011
5.18 more — Display files on a page-by-page basis . 1015
5.19 newgrp — Change to a new group . 1044
5.20 nice — Invoke utility with altered scheduling system priority . 1048
5.21 nm — Write the name list of an object file. 1053
5.22 patch — Apply changes to files . 1062
5.23 ps — Report process status . 1071
5.24 renice — Set system scheduling priorities of running
processes. 1079
5.25 split — Split into pieces . 1085
5.26 strings — Find printable strings in files . 1090
5.27 tabs — Set terminal tabs . 1094
5.28 talk — Talk to another user . 1098
5.29 time — Time a simple command . 1104
5.30 tput — Change terminal characteristics . 1108
5.31 unalias — Remove alias definitions . 1112
5.32 unexpand — Convert spaces to tabs . 1115
5.33 uudecode — Decode a binary file . 1121
5.34 uuencode — Encode a binary file . 1125
ix
5.35 vi — Screen-oriented (visual) display editor. 1129
5.36 who — Display who is on the system . 1177
5.37 write — Write to another user . 1180
Section 6: Software Development Utilities Option. 1187
6.1 ar — Create and maintain library archives . 1187
6.2 make — Maintain, update, and regenerate groups of programs . 1197
6.3 strip — Remove unnecessary information from executable
files . 1228
Annex A (normative) C Language Development Utilities Option . 1233
A.1 c89 — Compile Standard C programs . 1233
A.2 lex — Generate programs for lexical tasks . 1247
A.3 yacc — Yet another compiler compiler . 1266
Annex B (normative) C Language Bindings Option . 1287
B.1 C Language Definitions . 1287
B.2 C Numerical Limits . 1288
B.3 C Binding for Shell Command Interface . 1291
B.4 C Binding for Access Environment Variables . 1295
B.5 C Binding for Regular Expression Matching . 1295
B.6 C Binding for Match Filename or Pathname. 1314
B.7 C Binding for Command Option Parsing . 1319
B.8 C Binding for Generate Pathnames Matching a Pattern. 1322
B.9 C Binding for Perform Word Expansions . 1330
B.10 C Binding for Get POSIX Configurable Variables . 1333
B.11 C Binding for Locale Control . 1336
Annex C (normative) FORTRAN Development Utilities Option . 1337
C.1 asa — Interpret carriage control characters . 1337
C.2 fort77 — FORTRAN compiler . 1342
Annex D (informative) Bibliography . 1355
Identifier Index . 1359
Alphabetic Topical Index . 1365
Acknowledgments . 1401
x
Information Technology—
Test Methods for Measuring Conformance

to POSIX — Part 2: Shell and Utilities
Interfaces
Section 1: General
1.1 Scope
This document defines a standard for test methods for the interface to command
interpretation, or ‘‘shell,’’ services and common utility programs for application
programs. These test methods are derived from the definitions contained in
ISO/IEC 9945-2:1993 (IEEE Std 1003.2-1992) {9}, hereinafter referred to as
‘‘POSIX.2 {9}.’’ The services and programs described in POSIX.2 {9} are comple-
mentary to those specified by ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990) {8},
hereinafter referred to as ‘‘POSIX.1 {8}.’’
This standard has been designed to be used by both verification suite authors and
system implementors. However, it is intended to be a reference document and not
a tutorial on the construction of verification suites or implementations.
1.2 Normative References
The following standards contain provisions that, through references in this text,
constitute provisions of this standard. At the time of publication, the editions indi-
cated were valid. All standards are subject to revision, and parties to agreements
based on this standard are encouraged to investigate the possibility of applying
the most recent editions of the standards listed below. Members of IEC and ISO
maintain registers of currently valid International Standards.
1.2 Normative References 1
IEEE Std 2003.2-1996 INFORMATION TECHNOLOGY—POSIX
1)
{1} ISO/IEC 646:1991, Information technology — ISO 7-bit coded character set for
information interchange.
{2} ISO 4217:1995, Codes for the representation of currencies and funds.
{3} ISO/IEC 4873:1991, Information technology — ISO 8-bit code for information
interchange — Structure and rule for implementation.
{4} ISO 8601:1988, Data elements and interchange formats — Information inter-
change — Representation of dates and times.
{5} ISO 8859-1:1987, Information processing — 8-bit single-byte coded graphic
character sets — Part 1: Latin alphabet No. 1.
{6} ISO 8859-2:1987, Information processing — 8-bit single-byte coded graphic
character sets — Part 2: Latin alphabet No. 2.
{7} ISO/IEC 9899:1990, Programming languages — C.
{8} ISO/IEC 9945-1:1990 (IEEE Std 1003-1990), Information technology — Portable

Operating System Interface (POSIX ) — Part 1: System Application Program
Interface (API) [C Language].
{9} ISO/IEC 9945-2:1993 (IEEE/ANSI Std 1003.2-1992), Information technology —

Portable Operating System Interface (POSIX ) — Part 2: Shell and utilities.
2)
{10} ANSI X3.9-1978 (Reaff. 1989), American National Standard — Programming
languages — FORTRAN.
{11} ISO/IEC 13210:1994 (ANSI/IEEE Std 1003.3-1991), Information Technology —

Test Methods for Measuring Conformance to POSIX .
3)
{12} IEEE Std 2003.1-1992, IEEE Standard for Information Technology — Test

Methods for Measuring Conformance to POSIX — Part 1: System Interfaces.
________________
1) ISO and ISO/IEC documents can be obtained from the ISO office, 1 rue de Varembe, Case Postale
56, CH-1211, Geneve 20, Switzerland/Suisse.
2) ANSI documents can be obtained from the Sales Department, American National Standards
Institute, 1430 Broadway, New York, NY 10018, USA.
3) IEEE documents can be obtained from The Institute of Electrical and Electronics Engineers, Inc,
445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, USA.
2 1 General
TEST METHODS FOR SHELL AND UTILITIES INTERFACES IEEE Std 2003.2-1996
1.3 Conformance
1.3.1 Implementation Conformance
1.3.1.1 Requirements
A PCTS used to test the conformance of POSIX.2 {9} shall conform to the require-
ments and recommendations contained in this standard and to the requirements
and recommendations contained in POSIX.3 {11}.
1.3.2 Application Conformance
1.3.2.1 Strictly Conforming POSIX.2 Application
This standard does not specify test methods to determine whether or not applica-
tions conform to POSIX.2 {9}. This includes Strictly Conforming POSIX.2 Applica-
tions, ISO/IEC Conforming POSIX.2 Applications, Conforming
POSIX.2 Applications, and Conforming POSIX.2 Applications using Extensions.
1.3.3 Documentation Audit Conformance
1.3.3.1 Requirements
A conforming documentation audit used to test the conformance of the
POSIX.2 {9} PCD (also referred to as the PCD.2) shall conform to the requirements
and recommendations contained in this standard and to the requirements and
recommendations contained in POSIX.3 {11}.
1.3 Conformance 3
IEEE Std 2003.2-1996 INFORMATION TECHNOLOGY—POSIX
(Blank page)
IEEE Std 2003.2-1996
Section 2: Conformance, Terminology, and General Requirements
(The structure of this section mirrors that of POSIX.2 {9}. In some cases, subclauses in POSIX.2 {9}
have no specific assertions. In those cases, the subclause heading is included in this standard, but
there is no content for that specific subclause.)
2.1 Conventions
2.1.1 Editorial Conventions
This standard uses the following editorial and typographical conventions. A sum-
mary of typographical conventions is shown in Table 2-1.
Table 2-1−Typographical Conventions
_______________________________________________________________________
LLL
Reference Example_______________________________________________________________________
LLL
LC-Language Data TypeLlongL
LLLC-Language Function system()
LLL
C-Language Function Argument arg1
LLL
C-Language Global External errno
LLL
C-Language Header LLL
C-Language Keyword #defineLLL
LLLCross-Reference: Annex Annex A
LLL
Cross-Reference: Clause 2.3
LLL
Cross-Reference: Other Standard ISO/IEC 9999-1 {n}
LLL
Cross-Reference: Section Section 2LLL
Cross-Reference: Subclause 2.3.4, 2.3.4.5, 2.3.4.5.6LLL
LLLDefined Term (see text)
LLLDefinition Citation []
LLL
Environment Variable PATH
LLL
Error Number [EINTR]
LLL
Example Input echo Hello, WorldLLL
LExample OutputLHello, WorldL
LLLFigure Reference Figure 7-1
LLL
File Name /tmp
LLL
Parameter
LLL
Special Character
LLL
Symbolic Constant, Limit {_POSIX_VDISABLE}, {LINE_MAX}LLL
LLLTable Reference Table 6-1
LLL
Utility Name awk
LLL
Utility Operand file_name
LLL
Utility Option -c
LLL
Utility Option With Option-Argument -w widthLLL_L______________________________________________________________________LL
2.1 Conventions 5
IEEE Std 2003.2-1996 INFORMATION TECHNOLOGY—POSIX
The Bold font is used to show brackets that denote optional arguments in a utility
synopsis, as in
cut [-c list][file_name]
These brackets shall not be used by the application unless they are specifically
mentioned as literal input characters by the utility description.
There are two types of symbols enclosed in angle brackets (< >):
C-Language Headers The header name is in the Courier font, such as
. When coding C programs, the angle
brackets are used as required by the language.
Parameters Parameters, also called metavariables, are in italics,
such as . The entire symbol,
including the brackets, is meant to be replaced by the
value of the symbol described within the brackets.
Numbers within braces, such as ‘‘POSIX.1 {8},’’ represent cross-references to the
normative references clause (see 1.2). If the number is preceded by a B, it
represents a bibliographic entry (see Annex D). Bibliographic entries are for infor-
mation only.
In some examples, the Bold Courier font is used to indicate the output of the
system that resulted from some user input, shown inCourier.
Defined terms are shown in three styles, depending on context:
(1) Terms defined in 2.2.1 and 2.2.2 are expressed as subclause titles. Alter-
native forms of the terms appear in [brackets]. At the conclusion of this
type of definition, the designation of a standard within [brackets] indi-
cates that the text of the definition was copied from that standard, with
only editorial changes, if any.
(2) The initial appearances of other terms, applying to a limited portion of
the text, are in italics.
(3) Subsequent appearances of the term are in the Roman font.
Symbolic constants are shown in two styles: those within curly braces are
intended to call the attention of the reader to values in and
; those without braces are usually defined by one or a few related
functions. There is no semantic difference between these two forms of
presentation.
Filenames and pathnames are shown in Courier. When a pathname is shown
starting with ‘‘$HOME/’’, this indicates the remaining components of the pathname
are to be related to the directory named by the HOME environment variable of the
user.
The style selected for some of the special characters, such as, matches
the form of the input given to the localedef utility (see 2.5.2). Generally, the
characters selected for this special treatment are those that are not visually dis-
tinct, such as the control characters or.
Literal characters and strings used as input or output are shown in various ways,
depending on context:
6 2 Conformance, Terminology, and General Requirements

TEST METHODS FOR SHELL AND UTILITIES INTERFACES IEEE Std 2003.2-1996
%, begin When no confusion would result, the character or string is ren-
dered in the Courier font and used directly in the text.
’c’ In some cases a character is enclosed in single-quote characters,
similar to a C-language character constant. Unless otherwise
noted, the quotes shall not be used as input or output.
"string" In some cases, a string is enclosed in double-quote characters,
similar to a C-language string constant. Unless otherwise noted,
the quotes shall not be used as input or output.
Defined names that are usually in lowercase, particularly function names, are
never used at the beginning of a sentence or anywhere else that English usage
would require them to be capitalized.
Parenthetical expressions within normative text also contain normative informa-
tion. The general typographic hierarchy of parenthetical expressions is
{[()]}
The square brackets are most frequently used to enclose a parenthetical expres-
sion that contains a function name [such as waitpid()] with its built-in
parentheses.
In some cases, tabular information is presented inline; in others it is presented in
a separately labeled table. This arrangement was employed purely for ease of
reference and there is no normative difference between these two cases.
Annexes marked as normative are parts of the standard that pose requirements,
exactly the same as the numbered sections. They have been moved to near the
end of the document for clarity of exposition. Informative annexes are for infor-
mation only and pose no requirements. All material preceding page 1 of this stan-
dard (the ‘‘front matter’’) and the two indexes are also informative.
NOTES that appear in a smaller point size have one of two different meanings,
depending on their location:
— When they are within the normal text of the document, they are the same
as footnotes—informative, posing no requirements on implementations or
applications.
— When they are attached to tables or figures, they are normative and can
include requirements.
Text marked as examples (including the use of ‘‘e.g.’’) is for information only
except for C-language programs and program fragments used to represent algo-
rithms, as described in 2.1.3.
In some cases, certain characters are interpreted as special characters by the
shell. In the normative portions of this standard, these characters are shown
without escape characters or quoting (see 3.2). In all examples, however, quoting
has been used, showing how sample commands (utility names combined with
arguments) could be passed correctly to a shell (see sh in 4.56) or as a string to
the system() function.
Clause and subclause numbers correspond to the equivalent clauses and sub-
clauses in POSIX.2 {9}. Any exceptions state the equivalent POSIX.2 {9} clause or
subclause in parentheses following the title.
2.1 Conventions 7
IEEE Std 2003.2-1996 INFORMATION TECHNOLOGY—POSIX
The typographical conventions listed here are for ease of reading only. Editorial
inconsistencies in the use of typography are unintentional and have no normative
meaning in this standard.
2.1.2 Grammatical Conventions
Portions of this standard are expressed in terms of a special grammar notation. It
is used to portray the complex syntax of certain program input. The grammar is
based on the syntax used by the yacc utility (see A.3). However, it does not
represent fully functional yacc input, suitable for program use: the lexical pro-
cessing and all semantic requirements are described only in textual form. The
grammar is not based on source used in any traditional implementation and has
not been tested with the semantic code that would normally be required to accom-
pany it. Furthermore, there is no implication that the partial yacc code
presented represents the most efficient, or only, means of supporting the complex
syntax within the utility. Implementations may use other programming
languages or algorithms, as long as the syntax supported is the same as that
represented by the grammar.
The following typographical conventions are used in the grammar; they have no
significance except to aid in reading.
— The identifiers for the reserved words of the language are shown with a
leading capital letter. (These are terminals in the grammar. Examples:
While, Case.)
— The identifiers for terminals in the grammar are all named with uppercase
letters and underscores. Examples: NEWLINE, ASSIGN_OP, NAME.
— The identifiers for nonterminals are all lowercased.
2.1.3 Miscellaneous Conventions
This standard frequently uses the C language to express algorithms in terms of
programs or program fragments. The following shall be considered in reading this
code:
— The programs use the syntax and semantics described by the C Standard.
— The programs are merely examples and do not represent the most efficient,
or only, means of coding the interface. Implementations may use other pro-
gramming languages or algorithms, as long as the results are the same as
those achieved by the programs in this standard.
— C-language comments are informative and pose no requirements.
Further conventions are presented in
— Utility Conventions, 2.10, describing utility and application command-line
syntax.
— File Format Notation, 2.12, describing the notation used to represent utility
input and output.
8 2 Conformance, Terminology, and General Requirements

TEST METHODS FOR SHELL AND UTILITIES INTERFACES IEEE Std 2003.2-1996
2.2 Definitions
2.2.1 Terminology
For the purposes of this standard, the following definitions apply:
2.2.1.1 application: When the User Portability Utilities Option is supported,
requirements associated with the term application also shall be interpreted to
include the actions of the user who is interacting with the system by entering shell
command language statements from a terminal.
2.2.1.2 can: An indication of a permissible optional feature or behavior available
to the application; the implementation shall support such features or behaviors as
mandatory requirements.
2.2.1.3 implementation: An object providing to applications and users the ser-
vices defined by this standard.
The word implementation is to be interpreted to mean that object, after it has
been modified in accordance with the instructions of the manufacturer to
— Configure it for conformance with this standard;
— Select some of the various optional facilities described by this standard,
through customization by local system administrators or operators.
An exception to this meaning occurs when discussing conformance documentation
or using the term implementation defined.
2.2.1.4 implementation defined: An indication that the implementation pro-
vider shall define and document the requirements for correct program constructs
and correct data of a value or behavior.
When the value or behavior in the implementation is designed to be va
...