Joseph Kowalski writes:
> > The stability of the getconf built-in command-line interface and the
> > system variables documented in getconf(1) is Committed; its pathname
> > binding to /bin is Volatile. The getconf built-in supports additional
> > system variables not available for /usr/bin/getconf; these variables
> > are Project Private, and include names prefixed with "AST" and "_AST".
> >
> What does "its pathname binding" actually mean and is it /bin or /usr/bin?
Refer to the previous ksh93 case (2006/550). The "pathname binding"
feature is a mechanism by which ksh93 knows whether to invoke an
internal ("built-in") implementation of the function or an external
one.
> > These components will initially be used only by the Korn Shell 93
> > Integration Project (PSARC/2006/550). The proposed location of the
> > tools in /usr/ast/bin is consistent with the location used within
> > AT&T.
> >
> Ah, battling communities - my favorite.
I don't think it's an issue here. This is the location that was
_already_ discussed and approved as part of the previous project.
> > If the interface stability level of the shared libraries listed in
> > PSARC/2006/550 (libshell, libast, libdll, and libcmd) is promoted from
> > Project Private, the stability of the /usr/ast/bin components listed
> > below should be promoted to at least the same level, to allow
> > consumers of the former to build the appropriate message files.
> >
> This isn't declarative. It starts with "If". Are the promoted, and if
> so, to what?
No promotion, no change. It's a statement about what must occur in
the future _if_ any such project is undertaken. In other words, these
things are functionally linked -- if you promote one, then you need to
promote the other, or have a very good reason not to.
If it helps, just ignore that paragraph. It's not delivering
anything.
> Volatile I guess, but it needs to be explicit.
They remain as they are.
> > Interface Description Stability
> > --------- ----------- ---------
> > /usr/lib/libpp.so.1 AT&T ANSI C preprocessor library Project Private
> >
> Why is this interesting to list? (No harm, but I fear I might be
> missing something.)
It just stakes out turf; that's all.
> > A new package for AST (Advanced Software Technology) developer tools,
> > SUNWastdev, will be created, which includes all of the above
> > message-building components. These tools have a dependency on ksh93
> > and its libraries, as listed in PSARC/2006/550, and shall not be
> > integrated before the Korn Shell 93 Integration project.
> >
> What Metacluster is this package to be added to?
Good question -- Roland?
My guess would be that it doesn't belong in *any* metacluster, as it's
really only needed for ksh93 development. If you're going to put it
into one, then I think it goes in SUNWCall.
Joseph Kowalski writes:
> > One possible point of concern here is the `getconf' duplication. This
> > project delivers a separate implementation of that feature, so that we
> > end up having two (the ksh93 one is a strict superset), and they are
> > to be kept in sync by means of additional testing.
> >
> I recall a longer term plan would be to have a single implementation of
> this (and
> many of the builtin commands). Is this still the plan and getconf would
> be part
> of that? (Basically, is this duplication a short term expedient?)
As pointed out in a follow-up message, the duplication is much less
significant than I'd previously thought.
The ksh93 built-in "getconf" looks at the arguments and, if they're
not ones it recognizes, it execs the existing implementation on the
user's $PATH.
--
James Carlson, Solaris Networking <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
