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.
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.
-John
