Mike Kupfer wrote: > > >>>>> "Jim" == James Carlson <james.d.carlson at sun.com> writes: > > Jim> I'd rather see a single ksh, based on this reasoning: if ksh93 is > Jim> compatible enough that we're comfortable with inserting it as > Jim> /usr/bin/ksh, then this means to me that there's no further purpose > Jim> to the old Sun ksh except as a museum piece. If there is _any_ > Jim> purpose to having access to the old Sun ksh, then I'd question > Jim> whether we're all quite so confident that we're ready to do the > Jim> replacement at all. > > One of the issues that occasionally floats to the surface is whether > (and how many) customers really want the old ksh88 semantics. The > thinking was, if most customers find the ksh88 semantics to be a lose on > the whole (because it forces them to special-case Solaris),
Actually the current /bin/ksh shipped with Solaris is not compatible with ksh88 either, making it some very special breed (and a serious PAIN for application developers, users (for example command line editing is much improved in ksh93) and those who have to maintain this monster (for comparisation: ksh93 has a upstream and a community who works on fixes (as seen recently with the i18n fixes) and does active development of new versions - for Solaris /bin/ksh Sun alone has the whole work to maintain it which is IMO silly))). > then maybe > it's better to declare those semantics Obsolete. (And this is not just > the project team. I saw a discussion among PSARC members along those > lines.) The idea behind oksh was to provide a safety net for customers > who can't (or won't) readily convert their scripts to ksh93. IMO this safetly net is really required...as I said ksh93 is intentionally not 100% compatibe to ksh88 (leaving the compatibility issues between ksh88 and Solaris /bin/ksh alone (or better: Solaris ksh is NOT compatible to ksh88 which also requires software vendors to special-case Solaris)) as some design issues were fixed and undocumented behavour changed which likely requires some scripts to be adjusted manually. http://www.opensource.apple.com/darwinsource/Current/ksh-4/ksh/src/cmd/ksh93/COMPATIBILITY has a list of differences (still incomplete, however we can only find more differences if we do real testing after ksh93 becomes available in OpenSolaris (e.g. that people can test it without needing to compile&install it manually)) [snip] > Converting the #! line to /usr/bin/oksh can be done mechanically, though > I suppose there are probably gotchas that would make an update script a > little more sophisticated than just running sed. Porting to ksh93 takes > more thought. Yes, but some things should really be rewritten (or adopted) to use the new features provided by ksh93. A good example is the "patchadd" script which is hated for it's bad performance due the complex queries which are required. Until now it was suggested to test whether "perl" could be used - but looking at the functionality needed the simple usage of ksh93's associative arrays (arrays which take a string as index value (BTW: This can even be a multibyte string (e.g. japanese) which should please the i18n/l10n folks a lot :-) )) could boost the script a lot (e.g. O(n^2) could be reduced to O(1) in many cases, also arrays are no longer limited by artificial size limits (which prevented their usage in many many cases) and therefore the whole patch database can be processed in memory (ksh93's memory management is also much better and can deal with such cases (e.g. giant arrays) without problems)). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
