Hi! ----
General note: The email below contains some of the old history of dtksh in Solaris and some background why the ksh93-integration project was created. I would prefer to take this as a page in a history book and _not_ as opportunity to come up with the old flamewars about dtksh, support or any of the other related issues. We're now working on getting ksh93 integrated into (Open-)Solaris and trying to leave the old problems behind us. Thanks! :-) John Plocher wrote: > Josh Hurst wrote: > > WIll Sun FIX dtksh? Both experts in this field - David Korn and Roland > > Mainz have complained about dtksh being utterly broken because Sun > > used an unofficial alpha code as ksh basis. > > It depends on how you define broken. Trying to be precise, several > potential definitions of /broken/ come to mind: > > o Isn't the latest version > o Doesn't have the features I wish it had > o Doesn't work as documented > o Corrupts my data > o Panic()s or dumps core > > In this case, dtksh faithfully delivers the functionality found > in the version it was based upon (M-12/28/93d). Yes and no. AFAIK it's not based on the final ksh93 version 'd' code. And I think based on the version used that this code should have never been shiped with a production system (see below ; AFAIK some of the CDE vendors took action and either fixed the problems or just upgraded the ksh93 basis to a newer version to leave the issues of ksh93d alpha simply behind...). > Inasmuch as it > reflects that old codebase, it isn't broken just because it has > not been updated or because it doesn't have modern features. > Will Sun FIX dtksh? Yes, if it is broken. The problem for dtksh is a little bit more compliciated. We have a larger set of dtksh applications created by our lab staff to get a "simple" GUI interface (erm... my fault... I teached them shell scripting and then showed them dtksh and over all the years this has evolved into a multi-megabyte colletion of scripts (last time I checked this the CVS contained around 12MB of script code) ... and sometimes I wish I would be able to understand what half the stuff does (at least the situation improved a little bit since they read the "Amiga User Interface Style Guide" (which stopped them from putting buttons and other GUI elements into places where you would not expect them...) ... :-) ) and based on this experience I think that the version of dtksh in other CDE versions like those in AIX+HP/UX is usually much more stable than the Solaris version (but I am not sure how it was done... the rumor ranges from manual bugfixing up to a simple update of the ksh93 basis). Solaris dtksh currently suffer from several weired "instablities" (e.g. scripts acting "randomly" or causing crashes) which are coming from the ksh93 version being used and some items are problems in the libDtWidget/Motif codebase. For example during the development of the init.d startup script for Xprt (Xprint server) we tried to use dtksh - it worked without problems on our side but many users complained about weired script failures. It turned out the problem was related to the many "hits" reported by "dbx -check access" and Rational Purity... and finally it was decided to use /usr/bin/ksh instead since dtksh was not reliable and any attempt to get this problem to the attention of Sun simply failed or was "ignored" (and "yes"... I've collected some amount of anger about that (and my preference would be to avoid the resurrection of this theme unless someone wants to see me exploding...) ... ;-( ). Another unfortunate issue is (or was) that Sun's customer support recommended dtksh to customers who wanted to use ksh93 in Solaris... which I think was very very "unfortunate" (which is an understatement...) ... some customers like Irek's company took a closer look at the problem, realised that the instabilites appeared to be known within Sun and then thought that Sun support was taking the mickey out of them and started deploying their own ksh93 binaries with their products instead. The same problems and rants had at least one good thing... the issue was resurrected a year ago (with much tears, anger and _lots_ of wrath about the situation) and resulted in the proposal which became the ksh93-integration project (going after dtksh was considered useless given the support status of CDE in Solaris). > Will Sun upgrade > dtksh to some /new/ set of specifications and features? Probably > not. I don't think it's possible to "fix" the ksh93d base of dtksh - the code is too old (it predates the day when ksh93 was opensourced and misses lots of bugfixes) and futher modifications will make the situation only much worse than it. I think the only workable option is to update the ksh93 basis of dtksh to a newer version. And I am renewing my offer I did four years ago, a year ago and now again: If someone is interested in such a work and _willing_ to integrate this into Solaris 11 then please give me access to the dtksh sources (yes, I am willing to sign an NDA etc.) and I am doing the work. BTW: I wouldn't be worried about backwards-compatibilty. Remeber ksh93 is guarded by it's test suite which prevents accidental incompatibilities. If dtksh cannot be upgraded or fixed I am suggesting it's _removal_ from Solaris to avoid futher problems caused by it's current status (I am not kidding). > Could someone in OpenSolaris Land make a version of ksh93 > that could be used to replace dtksh? Absolutely. Erm... no. Not replace... but we could use libshell.so (which is ksh93's core provided as a shared library) in dtksh. Another, seperate project may be to dismantle dtksh and create something like a gtkksh or kdeksh using the same concepts. > Would Sun > adopt that version? I have no clue. As I said... if dtksh cannot be fixed using an upgrade it should be removed ASAP. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
