> Date: Thu, 24 Aug 2006 21:34:51 -0700 (PDT)
> From: David.Comay at Sun.COM
> To: Roland Mainz <roland.mainz at nrubsig.org>
> cc: April Chin <April.Chin at eng.sun.com>, Korn Shell 93
> integration/migration
project discussion <ksh93-integration-discuss at opensolaris.org>,
don.cragun at Sun.COM
> Subject: Re: [ksh93-integration-discuss] Re: update on ksh93 issues
> MIME-Version: 1.0
>
> > Yes... and IMO it would be useless to document that because then
> > everyone could step-up and demand the documentation of every single
> > "easter egg" in ksh93, too. Currently the only purpose of these bits
>
> I'm not sure if I want to even know what other sorts of "easter eggs"
> might be present in the shell.... ;-|
>
> But it's important to realize that ARCed does not imply documented at
> least in terms of user documentation.
Okay, if that is the case, I believe we have no issues including the
built-ins bound to /usr/ast/bin in the ARC case.
>
> > mapped to /usr/ast/bin/ are to have a quick&easy way to diagnose
> > problems within scripts (for example such a script may redice in a
> > read-only location and may therefore not be editable but may still honor
> > the externally-defined ${PATH} variable) which may depend on features
> > only available in the ksh93 builtins (for example the AST "msgcc" was
> > such an example).
>
> Perhaps I'm confused about what /usr/ast/bin is for. Can you please
> provide a clarification or pointer to some documentation or an email
> thread where this might have been discussed? I would have said that
> I'll wait for the ARC material but if that's missing details like this,
> then I think that's an issue.
/usr/ast/bin is just a fictional pathname which is used to turn
on the full set of built-ins that are available in AST's libcmd
library...these built-ins are commands that are almost all
available as binaries on Solaris:
basename
cat
chgrp
chmod
chown
cmp
comm
cp
cut
date
dirname
expr
fds
fmt
fold
head
id
join
ln
logname
mkdir
mkfifo
mv
paste
pathchk
rev
rm
rmdir
stty
tail
tee
tty
uname
uniq
wc
If there were commands in /usr/ast/bin, they would have compatible
behavior with the above, and they would presumably be the AST versions
of the commands, which call the same interfaces as the ksh93 built-ins.
Note that there are no plans to create a /usr/ast/bin directory of commands.
Since the above built-ins are bound to /usr/ast/bin, putting /usr/ast/bin
on the path first allows those users who depend on the AST built-in behavior,
in ksh93 (functionality not available on the Solaris versions of these
commands), to use them, without causing problems for users who
expect Solaris behavior of these commands.
>
> In general, any sort of interface (including ones like command line
> options or environment variables) which change the behavior of ksh93
> should be ARCed. If they're not intended to be used by general users
> or documented, they they can be ARCed as Project Private although with
> an explanation of what behavior they control.
>
> By the way, is the .paths mechanism described by David Korn in
>
> http://www.opensolaris.org/jive/thread.jspa?messageID=32986胚
>
> also going to be documented?
.paths is documented in the original ksh93(1) manpage, which is part of
the case.
However, I have been told that the .paths functionality, at least the
BUILTIN_LIB=value portion of it, will not work
unless we include the AT&T libshell.so as part of the installation.
Since we are adding three new Project Private shared libraries from AT&T--
libshell, libdll, and libast--only their versioned names, i.e.,
libshell.so.1, libdll.so.1, libast.so.1, will be exposed.
Their compilation environment names--libshell.so, libdll.so, and libast.so
--will not be included because these interfaces are project private, they
are subject to change, and we don't have complete documentation for them.
Understandably disabling .paths functionality is not desirable.
Right now I'm trying to clarify if
the absence of libshell.so, libast.so, and libdll.so actually does
cause a problem for .paths, and if so, what would need to
be removed or modified regarding .paths in the
proposed documentation for the ksh93(1) manpage in Solaris.
April
>
> dsc
