Roland Mainz wrote: > AFAIK this is not possible. The problem is that /usr/bin/getconf is > compiled as normal application while ksh93 in Solaris is explicitly > compiled as XPG6/C99 application (to enable various features and avoid > that the ksh93 code enables workaronds for older standards functions > (which result in both loss of features and performance)). > The problem is that compiling a Solaris application with the XPG6 flags > changes some "secret" libc master switches (|_xpg4| and |_xpg6|) which > change the behaviour of many libc functions to match the XPG6 standards, > including |sysconf()|, |pathconf()| etc. - which would make the > "getconf" builtin command work like /usr/xpg6/bin/getconf instead of > /usr/bin/getconf (and there is no workaround, neither running the > "getconf" builtin in a seperate child process with |_xpg4|+|_xpg6| set > to "0" (this doesn't work because it doesn't alter the different header > contents (and I doubt that code review would allow such a horrible abuse > of C64-style "poke"'ing)) or poking these values only at runtime of the > "getconf" builtin (end reset it in an exit trap) will work (this would > not be threadsafe)). > Maybe I'm just confused, but this seems to be a good explanation why /usr/bin/getconf can't be a tiny wrapper linking with the library which implements the builtins for ksh93 (I forgot name of said library - probably blocking it in the Freudian sense.)
Why couldn't the same *source* be compiled not in xpg mode to produce /usr/bin/getconf. I believe the concern was about sharing source, not about sharing the binary implementation. - jek3
