Glenn,
I apologize for taking so long to respond to this. I've been on a
conference call dealing with some of these standards committees...
Let me try a slightly different approach to this discussion...
The getconf utility was invented by POSIX.2-1992. SVID3 and XPG3
didn't have a getconf utility. We made getconf available in the
Solaris "default environment" in /usr/bin because of a chicken and egg
thing: An application not knowing about /usr/xpg*/bin needs to use
`getconf PATH' to start an application in an XPG4/POSIX.1-{1990 through
1996} environment (note that the POSIX.2-1992 getconf utility did not
have a -v option). Furthermore, our getconf utility processing of the
-v option is currently grossly lacking functionality. An application
should be able to use the command:
getconf -v specification PATH
with an appropriate value for specification to get back a setting for
$PATH suitable for use in a SVID3, XPG3, XPG4, SUS, SUSv2, SUSv3,
POSIX.1-{1990 through 1996}, POSIX.2-1992, or POSIX.1-2001 conforming
environment on a Solaris system and to get back other configuration
variables for all of the 32-bit and 64-bit programming environments
that current Solaris systems support. (This should be fixed before the
next Solaris minor release ships. This is hinted at by Solaris Bug ID
4891587 [*getconf* getconf utility -v option does not function as
defined], but there are several other related bugs.) Note that all
versions of getconf (/usr/bin, /usr/xpg4/bin, and /usr/xpg6/bin) know
about all of the configuration variables even though some configuration
variables aren't defined by all environments. (For example, XPG4 says
that the commands `getconf _XOPEN_XPG2' and `getconf _XOPEN_XPG3'
should return the string "undefined" if the system does not support an
X/Open Portability Guide Issue 2 or 3, respectively, programming
environment; and should return a defined (but unspecified) value if the
programming environment is supported. Since Solaris systems do not
claim to provide an XPG2 conforming environment but do provide an XPG3
conforming environment, all of our versions of the command `getconf
_XOPEN_XPG2' print "undefined\n" and all of our versions of the command
`getconf _XOPEN_XPG3' print "0\n" even though the POSIX.1-2001 and
SUSv3 (or XPG6) (for /usr/xpg6/bin/getconf) specifications say nothing
at all about these variables and SVID3 (for /usr/bin/getconf) doesn't
know about getconf at all.)
>Date: Thu, 16 Nov 2006 11:10:00 -0500
>From: James Carlson <james.d.carlson at Sun.COM>
>
>Glenn Fowler writes:
>> there is a mismatch between xpg4 compiled user programs and
/usr/xpg4/bin/getconf
>> maybe I didn't get the feature test macros right for xpg4/xpg4v2?
>> could you run the script on a solaris 11 machine and post the output
>
>I get the right answers when compiling for XPG4 (as per the
>standards(5) man page):
>
>$ c89 -D_XOPEN_SOURCE -D_XOPEN_VERSION=4 foo.c -o foo
>$ ./foo
>PASS_MAX=8 PATH=/usr/xpg4/bin:/usr/ccs/bin:/usr/bin:/opt/SUNWspro/bin
>
>> it is getting a bit clearer:
>> a user application with PATH=$(getconf PATH) can use getconf to
>> check the parameters for any other utility/application on $PATH
>> but once PATH is modified, some utilities/applications may not
>> correspond to getconf
>
>I'm not quite sure I follow. If an application uses PATH=$(getconf
>PATH), then it has entered the POSIX.2 environment. If it was
>previously in XPG6, it stays there (as that's a superset), but if it
>was in any "lower" environment, it goes to POSIX.2.
Not exactly. This is an example of a case where the value of $(getconf
PATH) depends on which version of getconf you invoke.
$(/usr/xpg4/bin/getconf PATH) has to return a value for $PATH suitable
for finding POSIX.2-1992 and XPG4 conforming utilities.
$(/usr/xpg6/bin/getconf PATH) has to return a value for $PATH suitable
for finding POSIX.1-2001 and SUSv3 (colloquially known as XPG6)
conforming utilities. We chose to make $(/usr/bin/getconf PATH) return
a value for $PATH suitable for finding the utilities for XPG4 and
POSIX.2 conformance since it allowed applications that didn't know
about /usr/xpg4/bin to find XPG4 and POSIX.2 programming environment
even if they didn't know about /usr/xpg4/bin. (At the time, I believe
that was the correct design. If we were implementing it for the first
time now, it could be argued that /usr/bin/getconf should return a
value for $PATH suitable for finding utilities conforming to the SVID3
and XPG3 specifications. I don't think it should change now for binary
compatibility reasons.)
- Don
>
>> for xpg in 000 300 400 402 500 600
>> do
>> case $xpg in
>> 600) cc=c99 ;;
>> *) cc=cc ;;
>
>"cc" doesn't give you a standards-compliant XPG4 environment, per the
>standards(5) man page. It's used for SVID3 and CAE XPG3.
>
>--
>James Carlson, KISS Network <james.d.carlson at sun.com>
>Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
>MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
