On Wed, 17 Jan 2007 07:57:01 -0500 James Carlson wrote:
> Roland Mainz writes:
> > The current (and likely only working) approach is to let the ksh93
> > "getconf" builtin forward all keys which are not owned by AST to the
> > native /usr/bin/getconf command (that's what we're currently doing).
> As long as "forward" here actually means "exec," that eliminates the
> issues I see.
"forward" means "exec"
(the implementation uses "defer")
the conditions for deferring to the native getconf on $PATH are any of:
(1) key unknown to builtin
(2) key known to have different values between { bin xpg4 xpg6 }
(3) any of { -a -v } options present
this lists the builtin getconf table
getconf -t
this lists the deferred (C:syscall D:minmax) keys
getconf -t | grep '[0-9] *[CD]' | grep -v 'VERSION_[0-9][0-9]'
the rationale for -last doing all this work is that it provides
char* astconf(char* name, char* path, char* value);
that
(a) keeps ast code #ifdef _SC_* free
(b) allows default minmax values to be synthesized on systems that don't
support specific keys but do support the feature named by the keys
(c) allows ast specific keys, like pathconf "directory is case ignorant"
for uwin/windows
(d) allows writable ast specific keys (listed by getconf -w)
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
