Re: "trap ... DEBUG" to execute before (instead of after) each

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

(Not sent to the mailing list, so I've quoted it in full and answered
underneath.)

nwsgpamachine@xxxxxxxxxxxxxxxxxx wrote:
> Dear Peter,
> 
> Thank you very much for your quick reply. Your help is very much
> appreciated. Let's continue the effort to make this really work.
> 
> I applied your patch to my version, which is 4.3.2 that I downloaded
> a while ago. I notice that your version of "options.c" is different
> from mine:
> 
>    mine:  {NULL, "debugbeforecmd",     OPT_EMULATE,		 DEBUGBEFORECMD
> },
>    yours: {{NULL, "debugbeforecmd",     OPT_EMULATE},		 DEBUGBEFORECMD
> },
> 
> but that is not the main problem. After changing the above line, the
> patched version compiled ok.
> 
> !! The BIG problem is that the patched version does not report 
> !! LINENO values correctly. 
> 
> (Before you send me your patch, I have actually tried out something
> along the same line as your changes in exec.c and I already noticed
> these problems then). Here is a test program:
> 
> ********************************************************************
> 
> #!/BUILD_DIR/zsh-4.3.2/Src/zsh
> 
> dbg() {
>    print "xx $1 yy"
> }
> 
> # setopt DEBUGBEFORECMD      # uncomment for second try
> trap 'dbg $LINENO' DEBUG; 
> 
> date
> x=2
> print $x
> 
> case $x in
>   1) print I am 1;;
>   2) print We are 2;;
>   3) print They are 3;;
>   *) print I don\'t know;;
> esac
> 
> ********************************************************************
> 
> When I run it with the DEBUGBEFORECMD option unset, I got the output
> 
>    *****************************************
>    *                                       *
> 1  *  xx 8 yy                              *
> 2  *  Wed Jan 10 01:16:51 CST 2007         *
> 3  *  xx 10 yy                             *
> 4  *  xx 11 yy                             *
> 5  *  2                                    *
> 6  *  xx 12 yy                             *
> 7  *  We are 2                             *
> 8  *  xx 16 yy                             *
> 9  *  xx 14 yy                             *
>    *                                       *
>    *****************************************
> 
> which is reasonablelele.
> 
> But when I run it with DEBUGBEFORECMD set, I got
> 
>    *****************************************
>    *                                       *
> 1  *  xx 11 yy                             *
> 2  *  Wed Jan 10 01:15:34 CST 2007         *
> 3  *  xx 12 yy                             *
> 4  *  xx 13 yy                             *
> 5  *  2                                    *
> 6  *  xx 20 yy                             *
> 7  *  xx 14 yy                             *
> 8  *  We are 2                             *
>    *                                       *
>    *****************************************
> 
> Note that all the LINENO is 1 more than the correct value. 
> 
> For example, line 1 above is the output of the DEBUG TRAP before the
> "date" command. It prints "xx 11 yy", but "date" is on line 10. In
> the first output (when DEBUGBEFORECMD is not set), line 3 gives the
> correct LINENO as 10.
> 
> When it comes to the "case" structure, the problem is even worse.
> First of all, it prints "xx 20 yy" (line 6), which refers to the
> statement "esac" (remember that LINENO is off by 1), whereas one
> would expect to see the statement "case" reported first. Another
> thing is that the output "We are 2" (line 8) comes from the
> statement "2) print We are 2;;" which is at line 16 of the script,
> but the DEBUG TRAP prints "xx 14 yy" (line 7 in the output) instead.
> 
> I don't know the source code enough to figure it out myself why this
> happened.
> 
> Would apprecaite if you can help to get to the bottom of these.
> 
> mk

Yes, I forgot about the line number stuff which isn't particularly well
implemented at the moment.  What happens is that execution of a command
(actually, the start of a pipeline) causes the line number to be set to
the value recorded for the code where that command occurs, which is
buried inside the parsed command (the wordcode).  This global line
number is then referred to by the LINENO variable.  Setting it in this
fashion happens too late for execution of the debug trap with the new
option.

I'm not quite sure how to deal with this at the moment; I'll think about
the neatest way, and if it can be combined with an improvement to the 
way the line number is handled.

-- 
Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/