Roland Mainz wrote:
> 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).
>
OK. Thanks for the explanation.
>
>>> 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... =:-)
>
I'm OK with this response. I wanted to be sure it had been considered.
Aside,... I always thought PATH was a great idea. I guess the FSH
authors (and Linux
developers in general) don't. Certainly throwing everything into
/usr/bin makes things
easy for the newbee, but it takes a great tool away from the (even
slightly) experienced
user.
>
>>> 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. ?
>
>
I think what I'm asking for is simply that that "If" be deleted from the
first sentence.
They *are* promoted, right? (Also, "is" then changed to "are".)
>> 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
> ?
>
OK.
The ARC case isn't required to list everything private, but it never
hurts. Since this goes
in a well known directory, it was probably a very good idea to list it.
As I said, I was
just making sure I hadn't missed something.
>
>>> 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/).
>
That's the answer I expected. Thanks.
- jek3
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20070117/19653bdf/attachment.html>
