>Date: Fri, 17 Nov 2006 10:34:42 -0500 >From: Glenn Fowler <gsf at research.att.com> > >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 >
Hi Glenn, >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 Understood. > >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 Great! I haven't seen all of your discussions on this issue with Roland, April, and Craig. In case new <name>s are added to the underlying getconf, does your built-in always call the underlying getconf when the built-in getconf doesn't recognize <name>? > >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 Good idea. I have filed RFE #6495035 to cover this suggestion. > >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? In general, getconf uses the <name> string specified by the underlying standard. There was, however, some some confusion in the underlying standards on several <name>s. XPG4 and XPG4v2 had a typo specifying CS_PATH rather than _CS_PATH in their descriptions of getconf <system_var> values. There was an inconsistency in XPG5 between normative text and examples in the c89 and getconf utility descriptions as to whether a leading underscore should be present on some of the programming environment <system_var> values. Therefore, our implementation allows _CS_PATH and _XBS5_* to be specified with or without the leading underscore to help users who may have been confused by these problems. - Don > >-- Glenn Fowler -- AT&T Research, Florham Park NJ --
