John Plocher wrote:
> I think it is time for an updated spec/issue roll up.
>
> Here is where I think things stand - please correct any
> misunderstandings:
>
> This project is an amendment to the Korn Shell 93 Integration project
> update 1 ARC case (PSARC/2008/094) specifying the following additional
> interfaces:
> 1) Update of ksh93 from upstream release ast-ksh.2007-12-15 to
> ast-ksh-2008-05-22
> 1.1) Update of ksh93
> 1.2) New "typeset" variable storage qualifier for function
> 1.3) New floating-point datatype "hexfloat" ("typeset -X varname)
> 1.4) New reserved options for "typeset".
> 1.5) New ksh93 math functions "ceil":
> 1.6) New reserved builtin "enum"
> 2) Project-private location for shell function library
>
> (Details:
> http://www.opensolaris.org/os/community/arc/caselog/2008/344/onepager/)
>
> There are 3 issues with the existing proposal: New keywords, release
> taxonomy and /usr/lib/shell.
>
> I think they all have been mostly resolved:
>
> 1) Introduction of hexfloat, enum and ceil into reserved namespace
>
> Commentary:
> hexfloat is simply a new argument to the typeset command.
> ceil is a math function that can't conflict with shell
> variables or function names.
> This leaves enum as the only potential name conflict.
>
> My judgment call is that this is OK. Why?
>
> Doing it now is better than either later or never. Impact on
> users at this point is zero - ksh93 is new to Nevada, it does
> not ship with S10. In addition, the upstream project team has
> a history of being extremely compatible - this is the first
> such addition in a dozen years, and it appears that no more
> additions are planned, so this should not turn into a chronic
> issue.
>
> Resolution:
> Not a problem.
>
> 2) Relationship of "t-, t, t+" versioning scheme and C-Team
> integration rules.
>
> Commentary:
> The upstream convention seems to be "no incompatible changes",
> "run API conformance test suites rigorously to ensure no
> regressions" and "moderate new feature additions based on
> [- +] release state"
>
> The boogie man is whether or not incompatible changes would show
> up in a "-" release, or if bugs would show up there that would
> cause equivalent breakage. Given the external team's almost
> obsessive focus on compatibility, I for one am not concerned
> about this at all.
>
> Resolution:
> Not a problem.
Agreed. Can the project team confirm your statement that no other such
additions are planned?
>
> 3) Creation of /usr/lib/shell as Project Private
>
> Commentary:
> The desire is to create a place to experiment with creating an
> environment for POSIX compatible shells to place and share
> middleware "library" code. This implies a whole bunch of stuff,
> most of which is non-obvious and not appropriate for Project
> Private classification.
>
> POSIX shells are usually the ones called "sh" - usually linked
> to include bash, korn, ash, dash, etc. The level of conformity
> to the official POSIX shell spec varies significantly between
> all these shells.
>
> Resolution (from Roland):
>
> Create /usr/lib/shell as a Volatile playground with the
> following initial expectations:
>
> A place to bundle shell function libraries _toegether_ in
> one common base directory, have them share functions
> via ${BASEDIR}/sh/ if the functions are in the POSIX
> shell syntax and in interpreter-specfic (e.g.
> ${BASEDIR}/zsh/..., ${BASEDIR}/ksh/...) if they use
> extended syntax... and handle the modules (one module
> may contain multiple functions) and functions in a
> DNS-like hieracy and allow pattern to be used as
> selectors.
>
> The intent is that shells will contain a builtin
> variable which points to the base directory so that
> consuming shell scripts do not need to know the
> absolute location where the library files are stored.
I would prefer to have the above slightly better specified... including,
what the variable name is, and how consumers will be able to use this.
(Including perhaps some examples of the hierarchy, and references to
what the file content is -- parsed scripts, precompiled shellcode,
shared objects, what?) Also, how will we get things like zsh or bash to
use these? (See David Comay's response and commentary on zsh's
/usr/share repository.)
HOWEVER, I recognize that this is Volatile, subject to change, and I
won't press too heavily for the above details. (I still think it would
be a good idea to have a more complete specification. Even if it is
going to change soon.)
-- Garrett
