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

["Rocky Bernstein" <rocky.bernstein@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3045 bytes --]

Thanks. This addresses one of the problem seen. There are still the
others -- output disappearing and weird line numbers shown further up
in the trace. But we will take these one at a time.

How do you feel about noting the subshell level in one of the
traceback stacks and allowing an optional parameter to set $LINENO in
those cases where it is reset to 1. (Is there a corresponding variable
for the filename?

I note that in
x="
$LINENO"

LINENO has the x's line number rather than the one it's on. No doubt
this is an artifact of xtrace wanting to show for tracing purposes x's
line. However probably more correct would be to keep that but have
$LINENO be the line that it itself is on.

However assuming this is what's desired,  attached is a test for the
recent lineno-in-subshell change as well as a test for the LINENO in
split assignment. Adjust that last test as desired.

I've put these in a separate file and my test would be to move some of
the other LINENO tests out of the overall variable test here, use
again adjust (or discard) as desired.

On Mon, Sep 29, 2008 at 4:52 AM, Peter Stephenson <pws@csr.com> wrote:
> On Sun, 28 Sep 2008 22:32:19 -0400
> "Rocky Bernstein" <rocky.bernstein@gmail.com> 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@csr.com>                  Software Engineer
> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
> Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070
>

[-- Attachment #2: V07lineno.ztst --]
[-- Type: application/octet-stream, Size: 354 bytes --]

# Tests of $LINENO variable
%prep

 mkdir lineno.tmp 
 cd lineno.tmp
 print 'a=1\nb="\n$LINENO"; print assignment lineno: $b\n(\n   c=$(print $LINENO); print backtick lineno: $c\n)' >lineno.sh

 
%test
  $ZTST_testdir/../Src/zsh ./lineno.sh
0:Checking split-line assignment LINENO and backtick subshell LINENO
>assignment lineno: 
>2
>backtick lineno: 5