"Christopher D. Quenelle" wrote: > The ksh that is integrated into Sun Studio dbx is based on an old > implementation of 'pdksh'.
Ouch... OUCH... ;-( That sounds really like a pain... > We have long wanted to be able to replace this shell with a more > modern shell of some kind (specifically for i18n support). > Ideally we want to create a dbx API that would support integration > into multiple shells, Umpf.. this is likely going to be very difficult. AFAIK no shell except ksh93 has a public API and doing the reverse is likely very difficult, too. My original plan was to modify "dbx" to use libshell.so (which is ksh93's core provided as a shared library) - which means that "dbx" would only be responsible to provide the extra commands required for debugging on top of ksh93 functionality (e.g. similar to the way how things like "tksh" are implemented). An alternative implementation may be to convert "dbx" into a loadable module for ksh93 - which would work the same way for the end-user as the proposal above except that other ksh93-based shells like "tksh" (Tcl/Tk-enhanched ksh) or "dtksh" (ksh with CDE/Motif/X11 widget support) could use "dbx" functionality, too (/opt/SUNWspro/bin/dbx would then be a dumb wrapper shell script which simply loads the shared dbx module and it's builtin commands). Judging which of both implementation is better depends little bit on how "dbx" is currently be implemened... > but the mixing of the grammars between dbx > and ksh is problematic. What do you mean here exactly ? Do you mean that "dbx" depends on ksh syntax in some cases or something else ? > I don't have any agenda here, I just figured this background > information might be useful to the folks here ... Is there a way to look at the current "dbx" sources to see how it is implemented right now ? It could help a lot to decide how to proceed... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
