[ksh93-integration-discuss] ksh93 Integration Update 1 Amendments1 [PSARC/2008/344FastTracktimeout 06/03/2008]

[John Plocher]

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