[ksh93-integration-discuss] Re: Planning the final ARC case forthe first ksh93-integration putback...

[Glenn Fowler]

On Thu, 16 Nov 2006 11:55:06 -0800 (PST) Don Cragun wrote:
> Yes.  And this is why I've been concerned about built-ins in ksh93 that
> replace /usr/xpg*/bin variants of standard utilities without adjusting
> for the differences in the way the standards require them to work.

Don et al, thanks for all of the input

background: reasoning for ast/ksh having its own getconf builtin
goes to the days when many systems had 0 getconf's -- this includes
uwin where we had to provide 1 full implementation from scratch

we stuck with it to fill in native system holes to smooth differences
between systems from the perspective of a script writer

the underlying astgetconf() function, a string interface, also
cleaned up ast C code nicely -- no #ifdef's for _SC_* etc.,
and besides, there's no edict against _SC_* being enum's immune to #ifdef

foreground: I am 99% close to getting full solaris functionality
(achieved in the edge cases by deferring to the underlying geconf on PATH)
and hope to get the final 1% today

the discourse has been good and has tightened up the ast implementation
for all target architectures, especially w.r.t. diagnostics

which brings me to a nit about the solaris getconf diagnostics
almost all errors, except "unknown name", punt to a usage message
it would be nice to be directed to details like "name requires path" or
"name does not require path" instead of usage

Don, one more question:
is there a general rule laid out somewhere for the difference
between FOO and _FOO, or is it on a name by name basis?

-- Glenn Fowler -- AT&T Research, Florham Park NJ --