Chris Quenelle wrote:
>
> > Mhhh... maybe that's something which could be done in ksh93... CC:'ing
> > the ast-users mailinglist - maybe someone there has an idea how this
> > behaviour could be emulated via ksh93... the tricky part is that '>' is
> > actually a special shell symbol which is AFAIK interpreted before the
> > command ("print") itself... ;-/
>
> Yes, it's a messy problem from an API separation point of view.
Do you have something like a BNF description for the Sun-extended "dbx"
?
> > BTW: Is this a feature of the original "dbx" or was that added later by
> > Sun ?
>
> This was added by Sun many moons ago.
We cannnot get rid of such extensions, right ?
BTW: Did you see (you're not subscribed...) David Korn's posting about
using ksh to interpret the user input and simulate the syntax extensions
?
> I would really like a clean dbx internal API so we could support writing
> dbx scripts in perl or ruby or whatever.
See my previous posting about turning "dbx" into a loadable module for
"ksh93". Such a loadable module can be used from "perl", too (you may
need language-specific wrapper functions for each interface style, e.g.
one for each of ksh93, perl, JNI etc.). We've done that lots of times
before, using the same modules from dtksh, tksh, perl and JNI (note: JNI
requires to make all interfaces threadsafe).
> But for interactive users,
> they won't want to put single quotes around every single language expression.
> Such language expressions are too common.
Hmmpff... in the worst case we have to hack full interpreter do deal
with the dbx syntax, but AFAIK there are ways to work around it. I am
not fully sure whether your extensions are context-sensitive or not
(we'll be in trouble if the Sun-extended dbx syntax is context-sensitive
- then we have to write a full interpreter in ksh - otherwise just
clever ksh hacking is required).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
