Re: DEBUG_CMD_LINE (Was Re: PATCH: skip command from debug trap)

[Peter Stephenson <pws@xxxxxxx>]

On Wed, 6 Aug 2008 17:19:14 -0400
"Rocky Bernstein" <rocky.bernstein@xxxxxxxxx> wrote:
> > (By the way, it wouldn't be too hard, if not completely trivial, to pass
> > down the code about to be executed in a variable, say DEBUG_CMD_LINE, as
> > reconstructed text, i.e. the same sort of format as what you get if you
> > get the shell to output a shell function that's already loaded.  But
> > it's messy enough that I won't unless it's definitely useful.)
> 
> My secret plan was to get the debugger working enough for folks to
> realize this would be useful. In bash the variable $BASH_COMMAND holds
> the command that is up for execution next. It is not the "line"  (as
> suggested in the name DEBUG_CMD_LINE)
> but the last command or statement.

That's not quite how it works in zsh at the moment.  The DEBUG trap is run
at the level of a "sublist", which is anything separated by ;, &, end of
line, or special terminators in certain cases (e.g. end of case markers) so
in your examples

>    [[ -z $FOO ]] && bar || baz
>    temp=x; x=y; y=temp

the sublists are

[[ -z $FOO ]] && bar || baz
tmp=x
x=y
y=temp

and you get one execution of the trap for each group.  So DEBUG_CMD_LINE
would include the whole of each sublist.

Without having looked at it in depth, it sounds is if zsh is being a bit
more structure-based rather than line-based compared with bash.

It would be possible with a bit of fiddling to get the DEBUG trap to happen
at the level of elements of a sublist, i.e. commands separated by && and
||, but I'm not sure if that's worth it.  Beyond that you run into the
hideous complexity of pipelines and I don't think it can be pushed that far
down.

-- 
Peter Stephenson <pws@xxxxxxx>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070