Interpretations

Answering questions that may arise related to the meaning of portions of an IEEE standard concerning specific applications.

IEEE Standards Interpretations for IEEE Std 1003.2™-1992 IEEE Standard for Information Technology--Portable Operating System Interfaces (POSIX®)--Part 2: Shell and Utilities

Copyright © 1996 by the Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue New York, New York 10016-5997 USA All Rights Reserved.

Interpretations are issued to explain and clarify the intent of a standard and do not constitute an alteration to the original standard. In addition, interpretations are not intended to supply consulting information. Permission is hereby granted to download and print one copy of this document. Individuals seeking permission to reproduce and/or distribute this document in its entirety or portions of this document must contact the IEEE Standards Department for the appropriate license. Use of the information contained in this document is at your own risk.

IEEE Standards Department, Copyrights and Permissions, 445 Hoes Lane, Piscataway, New Jersey 08855-1331, USA

Interpretation Request #156
Topic: shell Relevant Clauses: 3.14.13

(1) If the shell accepts as an extension the conditions with a leading SIG prefix, will it be permitted to print this prefix when trap has no operands? An example is GNU's bash: (input)> trap xxx ALRM (input)> trap trap -- 'xxx' SIGALRM and bash allows that last form to be used as input, too.

(2) Does the wording ``..., so that it is suitable for re-input to the shell as commands that achieve the same trapping results.'' (lines 1754-1756) mean that traps set to their default value must be listed? As an example, consider a function which sets its own traps: f () { oldtraps=3D"$(trap)" trap 'xxx' USR1 .... eval "$oldtraps" } trap - USR1 f Will SIGUSR1 be handled now with the command xxx--as is the case with historic sh and bash--or must it be reset to its default behaviour?

Interpretation Response
Question 1: The standard clearly states that the condition should not have the leading SIG. While extensions might allow implementations to accept a leading SIG, the output would be less portable if this was produced. The condition never has SIG ... strings that have SIG can be interpreted as condition by removing SIG. Therefore bash is non-conforming with respect to output (though input is fine).

Question 2: The standard is unclear on this issue. Section 3.14.3 Line 1752 talks about "commands" rather than "actions". If commands are the subset of actions that consist of a non-null string that is not "-", then it is impossible to meet the conditions given on lines 1754-6. Nearly all (or all known) implementations fail to meet the conditions on line 1754-6. No conformance distinction can be made between alternative implementations based on this. This is being referred to the sponsor.

Rationale for Interpretation
None.