Roland Mainz wrote:
> 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"
> ?
We have a yacc grammar inside the dbx sources, but I'm not free
to post it for now.
>
>
>>>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
> ?
The extensions are widely relied on by the current users of Sun dbx.
I don't think it would be helpful to just drop them.
I read David's posting. The solution gets more complicated
if we also want to support other shells besides ksh, and if we
want to allow embedding dbx-style commands inside a ksh-style command,
and embedding a ksh-style command inside a dbx-style command.
(dbx) stop in $KSH(for i in 1 2 3; do echo "func$i"; done)
(ksh) for i in 1 2 3; do echo $DBX(print func$1()); done
I have some ideas for I would like to see out of a proper
shell integration with dbx, I'll post them on my blog
when I get a chance.
>
>
>>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).
Yes, this is exactly what I'd like to do. Today, the internal
interface we use for this is in C++. That makes things a little
harder, but not impossible.
>
>
>>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).
I'm not sure I know what you mean by "context sensitive" here.
The meaning of '>' is definately context sensitive (as I mentioned before).
It depends on whether you are evaluating a ksh-style command or
a dbx-style command. Most dbx commands are actually interpreted
in ksh-style mode, for this purpose. There are a small number
of commands that take language expressions and need to use
different parsing rules. Unfortunately those include the
most-used commands ('print' and 'stop' etc).
eg: stop in foo -if a > b
--chris
