Re: Help me track down a tough bug? (probably funcfiletrace, subshells and possibly I/O redirection)

[Peter Stephenson <pws@xxxxxxx>]

On Sun, 28 Sep 2008 22:32:19 -0400
"Rocky Bernstein" <rocky.bernstein@xxxxxxxxx> wrote:
> In general I think this will help. Not just because it helps the
> debugger. Later (* * * * below) I'll elaborate on this.
> 
> But in short, either this patch doesn't solve this particular problem
> or I hand-applied the patch incorrectly.
>...
> When I run zsh with those patches on this program:
> (
>     x=$(print $LINENO); print $x
> )
> 
> I still get 1. Is that what one gets with the patch applied?

No, you should get the line number in the file as I do, and you shouldn't
get any additional test failures.  I don't think your version is working.

I've now committed it, but with one additional change:  parse_string()
still has the key additional reset_lineno logic, but it once again always
saves and restores the line number locally.  That wouldn't make a
difference in this particular case but sometimes with the previous version
(I haven't bothered tracking down the exact places) you might get the
global line number being incremented too much.  I don't think there's any
case where parsing the string should affect the line number from the
surrounding context.

> Let me see if I understand the situation correctly: there is an
> internal routine called parse_string() which can be called though eval
> as well as backtick. For eval, one can argue its the right thing, but
> for backtick seeing 1 as the value of $LINENO might be a bit odd.

Right.  However, I've now tried to arrange it so that the line number is
only reset in places where zsh provides (through the function stack) enough
supporting for finding out what's actually going on.

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