Joseph Kowalski wrote:
[snip]
> James Carlson wrote:
> > 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
(Somewhere April wrote a better (and shorter explanation) but I can't
find it right now... ;-( )
Path name binding means that a builtin is bound to a specific path. The
shell will execute the command in place of the "native" command in the
filesystem if it's found at the path lookup in ${PATH}.
For example if you have a builtin command "grabvictim" bound to
/opt/tentaclemonster/bin/grabvictim then the builtin "grabvictim" will
only be executed if ${PATH} contains /opt/tentaclemonster/bin/ and no
other version of "grabvictim" was found in a ${PATH} element before this
point (="/opt/tentaclemonster/bin/").
As alternative builtin commands can be added without a path binding
which means they will be executed immediately ("print" and "sleep" are
examples for such builtin commands).
> and is it /bin or /usr/bin?
It is both /bin/ and /usr/bin/ - the code detects whether "/bin" is a
softlink to "/usr/bin" and then binds commands bound to "/bin"
automagically to "/usr/bin", too (they're the same filesystem objects
anyway and a different behaviour would be confusing for script authors).
> > 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.
Uh-oh... ;-(
> We get some degree of flack from the Linux FSH crowd about creating project
> specific directories in /usr.
How else should the "namespaces" between different projects be defined ?
The ${PATH}/${FPATH} stuff was exactly invented to avoid collisions
between projects and give full control over the lookup order (which is
quite usefull if you want to implement multiple different standards
(e.g. XPG4 in /usr/xpg4/bin, XPG6 in /usr/xpg6/bin, AST in /usr/ast/bin,
UCB in /usr/ucb etc.)). and use them in a mix&match way in the same
operating system instance.
> The charming FSH spec simply says, "don't
> do this"
> without saying what to do. It seems like the standard response is to
> put such things
> either in /opt (reasonable, but a problem for Solaris diskless/zones) or
> under /usr/lib
> (completely silly in all respects, IMHO, it just moves the problem to
> another
> directory, one that is repeatedly scanned by ld.so - go figure).
>
> I guess if ksh93 installed on a Linux system installs into /usr/ast,
> with the resultant
> wrath of the FSH zelots, we have no problem. If it installs elsewhere,
> we need to
> have the discussion as to if we should be like Linux or be like legacy
> Solaris.
Usually the AST tools are installed in either /usr/ast/ or /opt/ast/
depending on the preference of the package builder. We'd like to go for
/usr/ast/ since ksh93 should be a more integral part of Solaris (we're
building it as part of OS/Net, remember ? :-) ) and not some kind of
external software which is tacked-on later (all stuff which goes into
/opt).
> Aside: For those who don't know, I personally view the FSH document to
> be one of the
> worst specifications ever created, but there are zelots out there who
> think it was
> written on stone tablets. Sigh,...
... yeah... it's funny to see how they try to deal with the problem that
some tools have the same name... =:-)
> > 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?
Uhm... to the same level as needed by the consumers of
libshell/libcmd/libast etc. ?
> Volatile I guess, but it needs to be explicit.
> > 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's a new filesystem object... AFAIK the ARC case must list them, right
?
> > 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?
AFAIK April can answer that better than I... but I guess it belongs to
the development cluster (e,g, similar to the packages which deliver into
/usr/css/bin/).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
