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

["Rocky Bernstein" <rocky.bernstein@xxxxxxxxx>]

My mistake. You are correct. This bug was introduced in paring down
the program and removing an initial truncate output (leaving the
subsequent append outputs). And I now see the answer to why output was
disappearing in the subshell which was my initial concern.

Thanks for all the help!

Any thoughts on marking subshell level inside one of the stack traces
or having return inside trap DEBUG with a negative number cause an
immediate return?

Thanks again.



On Tue, Sep 30, 2008 at 12:53 PM, Peter Stephenson <pws@xxxxxxx> wrote:
> On Mon, 29 Sep 2008 20:18:52 -0400
> "Rocky Bernstein" <rocky.bernstein@xxxxxxxxx> wrote:
>> zshdb<3> p ${funcfiletrace[@]}
>>
>> ./command/eval.sh:11 ./command/eval.sh:27 ./lib/processor.sh:96
>> ./lib/processor.sh:44 ./zshdb2.sh:9 ./testing.sh:3 ./zshdb2.sh:34
>> ./command/eval.sh:11 ./command/eval.sh:27 ./lib/processor.sh:96
>> ./lib/processor.sh:44 ./zshdb2.sh:9 ./testing.sh:3 ./zshdb2.sh:34
>> ./zshdb2.sh:9 ./testing.sh:3 ./zshdb2.sh:34
>> # Were did that double set of lines come from?
>
> Hmmm... I'm not convinced this has got anything directly to do with the
> shell rather than the debugger.  Here's what I get when I simply ask for
> the PID repeated times:
>
> ---------------
> ./zshdb2.sh:7 ./zshdb2.sh:34
> ===============
> (./zshdb2.sh:34):
> . ./testing.sh
> ./zshdb2.sh:9 ./zshdb2.sh:34
> zshdb<1> p $$
> 711
> ./zshdb2.sh:9 ./zshdb2.sh:34
> zshdb<2> p $$
> 711
> 711
> ./zshdb2.sh:9 ./zshdb2.sh:34
> zshdb<3> p $$
> 711
> 711
> 711
> ./zshdb2.sh:9 ./zshdb2.sh:34
> zshdb<4>
>
> It looks like something is odd with whatever is holding the command to be
> executed.  You know better than me how that works.

Sorry you are correct. This bug was introduced in paring down the
program. Line 6 of lib/eval.sh should be:

  print "$@" > $_Dbg_evalfile

rather than

print "$@" >> $_Dbg_evalfile

However after this is fixed we have the disappearing output when in
that 2nd set of subshells which is the problem that motivated all of
this. What you want to print or eval is written to _Dbg_evalfile along
with some other commands to try to simulate the environment you were
in before entering the debugger. Then that file is sourced via:

   if [[ -t $_Dbg_fdi  ]] ; then
       _Dbg_set_dol_q $_Dbg_debugged_exit_code
       . $_Dbg_evalfile >&${_Dbg_fdi}
   else
       _Dbg_set_dol_q $_Dbg_debugged_exit_code
       . $_Dbg_evalfile
   fi

Somehow in that context no output appears even though output may be
explicitly written to a terminal file descriptor in the first branch.
I've also have tried using just the "else" branch above and still no
output. Finally, you can remove the call to _Dbg_set_dol_q which is
just setting $? before source'ing the file and that still doesn't
cause output to reappear.

So there seems to be something funky with I/O inside a backtick
subshell. I don't get that problem inside a () subshell, even if
output has been redirected on that, e.g.

( x=1)>/dev/null
because the debugger output goes to _Dbg_fdi.
> --
> Peter Stephenson <pws@xxxxxxx>                  Software Engineer
> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
> Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070
>