Glenn Fowler writes:
> /usr/bin/getconf somehow chooses between xpg4 and not
> is PATH a special case?
It doesn't really "choose." It just passes along what sysconf and
confstr report.
> put another way, if PASS_MAX can be not-xpg4, why couldn't PATH too?
The two are defined differently. PASS_MAX in sysconf(3C) gives you
the maximum password length, which is a function of the way the
application is compiled and linked -- that is, to which standard it
conforms. PATH in confstr(3C) is defined to give you a value that you
can use to run a command inside of a particular environment,
regardless of how the current application is linked.
> also, on that solaris 11 machine, can you post what
> confstr(_CS_PATH, ...)
> returns for a test prog compiled with default options
That'd be the same as /usr/bin/getconf. Here's a quick hack:
$ cat > foo.c <<EOF
#include <stdio.h>
#include <unistd.h>
void main(void) {
char path[1024];
confstr(_CS_PATH, path, sizeof (path));
puts(path);
}
EOF
$ cc foo.c -o foo
"foo.c", line 5: warning: implicit function declaration: confstr
$ ./foo
/usr/xpg4/bin:/usr/ccs/bin:/usr/bin:/opt/SUNWspro/bin
$
> this isn't a drop dead issue -- I'd just like to understand
> the situation enough to be able to predict where
> /usr/bin/getconf foo
> pulls its data from
As documented in the man page, it gets its data from confstr(3C) and
sysconf(3C).
> at this point n>1 getconf's, along with -v, and a dependence on
> compile time -D's affecting <limits.h> and sysconf(_SC_*) etc.
> values is making about as much sense as the registry
> and that's scary
The fact remains that Solaris supports multiple standards-conformant
environments, and that each has different attributes.
If there were just one standard, things would be much simpler. :-/
--
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
