Parameter-handling discrepancy in debugger when stepping

May 23, 2010
60
1
Seattle
In the following example:
  • The main routine gets the first batch parameter and strips it off. It then calls SUBR, which does the bulk of the work.
  • SUBR calls SUBR2, which gets the next batch parameter and strips it off.
  • SUBR then processes the rest of the parameters.
Code:
[D:\TMP] type foo.btm
@ echo off
  echo Input parm string is %*
  echo parm1 starts out %1
  shift
  echo after shift, parm1 is %1
  gosub subr
  echo at end, parm1 is %1
  quit

:SUBR
  gosub SUBR2
  echo in SUBR, processing remainder of parms, which are %$; parm1 is %1
  do while (%1) ne ()
    echo In SUBR loop, parm1 is %1
    shift
  enddo
  return

:SUBR2
  echo In SUBR2, parm1 is %1; shifting out
  shift
  return
The output is as I expected (pay attention to the parameters that SUBR sees):
Code:
[D:\TMP] foo /mainoption /secondoption set1 set2 set3
Input parm string is /mainoption /secondoption set1 set2 set3
parm1 starts out /mainoption
after shift, parm1 is /secondoption
In SUBR2, parm1 is /secondoption; shifting out
in SUBR, processing remainder of parms, which are set1 set2 set3; parm1 is set1
In SUBR loop, parm1 is set1
In SUBR loop, parm1 is set2
In SUBR loop, parm1 is set3
at end, parm1 is
If I simply run to end in the debugger, it produces identical output. However, if I step through the entire code, SUBR does not see any batch parameters:
Code:
Input parm string is /mainoption /secondoption set1 set2 set3
parm1 starts out /mainoption
after shift, parm1 is /secondoption
In SUBR2, parm1 is /secondoption; shifting out
in SUBR, processing remainder of parms, which are ; parm1 is
at end, parm1 is
I thought this had something to do with GOSUBs more than one level deep. But if I comment out the call to SUBR2 and step through the code again, it produces equally disturbing results: the first two of the remaining batch parameters are seen, but the last two are skipped.
Code:
Input parm string is /mainoption /secondoption set1 set2 set3
parm1 starts out /mainoption
after shift, parm1 is /secondoption
in SUBR, processing remainder of parms, which are /secondoption set1 set2 set3; parm1 is /secondoption
In SUBR loop, parm1 is /secondoption
In SUBR loop, parm1 is set1
at end, parm1 is
Am I seriously abusing batch parameter references, or is this a bug?
 
May 20, 2008
11,798
118
Syracuse, NY, USA
Hmmm! It's OK here using any of the stepping buttons. Using "step into" 21 times I get this, which looks correct.

Code:
Input parm string is /mainoption /secondoption set1 set2 set3
parm1 starts out /mainoption
after shift, parm1 is /secondoption
In SUBR2, parm1 is /secondoption; shifting out
in SUBR, processing remainder of parms, which are set1 set2 set3; parm1 is set1
In SUBR loop, parm1 is set1
In SUBR loop, parm1 is set2
In SUBR loop, parm1 is set3
at end, parm1 is
 
May 23, 2010
60
1
Seattle
That's what I'm doing: "step into". So something must be different about my setup. What could that possibly be?

Take Command v28.01.14 x64
Windows 10 Pro
 
May 20, 2008
11,798
118
Syracuse, NY, USA
I'm starting it like this.

Code:
bdebugger coot.btm /mainoption /secondoption set1 set2 set3

Maybe build 18 will fare better.
 
May 20, 2008
11,798
118
Syracuse, NY, USA
I also tried "start debugging" then entering the parameters in the watch dialog, as
Code:
1=/mainoption
2=/secondoption
...

That was OK also.[/code]
 
May 23, 2010
60
1
Seattle
I was entering the parms in the ribbon in the debugger.

Going to 18 fixed it. Thanks, Vince!
 

Similar threads