IEEE Standards Interpretation for IEEE Std 1003.1™-2001 IEEE Standard Standard for Information Technology -- Portable Operating System Interface (POSIX®)
Copyright © 2006 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 #47
Topic: XBD 8.1 Environment Variable Defn Relevant Sections: XBD 8.1 Environment Variable Defn Page: 161 Line: 5584
Can conforming implementations require all-caps environment variables to be set to particular values, as part of the configuration instructions?
The standard says "Environment variable names used by the utilities ... consist solely of uppercase letters, digits, and the '_' (underscore) ... and do not begin with a digit." Let's call these names "all-caps" for short. The question is whether an implementation can insist on a particular all-caps variable (or variables) being set to particular values, in order to establish a conforming environment. Clearly variables whose names contain lower-case letters are reserved for applications and cannot affect the behavior of utilities, and it's also clear from confstr() that an implementation can require PATH to be set to the output of the command "getconf PATH" in order to get conforming behavior, but it's not clear from the standard whether an implementation can require any other all-caps variable to be set.
On one side of the issue, requiring an all-caps variable to be set is common implementation practice. AIX requires XPG_SUS_ENV='ON'. HP-UX requires UNIX95 to be set. IRIX requires _XPG to be set to a numeric value greater than 0. UnixWare requires POSIX2='on'. GNU utilities require POSIXLY_CORRECT to be set. In general these environment settings can affect the behavior of utilities, functions, and other facilities.
If an application defines an environment variable not specified by the standard or adds a nonstandard option to a command line, an implementation is free to do whatever it wants. But, an implementation that requires an application to define a nonstandard environment variable to get standard behavior is not a conforming implementation.
He further gave this example. If "env" and "getconf" conform to the standard, then
env -i PATH=$(getconf PATH) command
must invoke "command" in a POSIX-conforming environment in which only the PATH variable is set; if an implementation requires (say) POSIXLY_CORRECT to be set as well for conformance, it will not execute the command correctly in general.
This question came up recently in the austin-group-l while discussing draft AI-027, but it is a different issue and deserves a separate Aardvark.
My own feeling is that the standard is unclear, and that widespread existing practice indicates that conforming implementations can require certain all-caps environment variables to be set.
In XBD section 8.1 page 161 line 5584, change ... and do not begin with a digit to ... and do not begin with a digit; setting or unsetting any variable in this name space results in unspecified behavior unless the variable is defined in this standard.
Append the following after XCU section "env" page 354 line 13663:
The utility might be invoked in a nonconforming environment if "env" is directed to set (or with -i, unset) a variable whose name falls in the space reserved to the implementation (see XBD section 8.1 page 161).
Interpretation Response #47
The standards states the requirements for access(), and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.
Rationale for Interpretation