bdebugger / ide usage confusion

[topherius]

I'm trying to use the bdebugger / ide functionality in TCC 15.01.52 x64 and I don't understand how to invoke the debugger in the current directory I'm using.

For instance, when I type 'bdebugger batch.btm' for the batch file residing in the subdirectory e:\code\, I get a dialog from the debugger that it can't find the file c:\batch.btm. Why is the debugger looking for the file in the root system drive?

Then if I manually load batch.btm in the debugger and try to step through it, it starts executing in the root system drive (C:\) as well, rather than my current working directory. Again, I don't understand this behavior.

I hope I'm missing something obvious. Any help? Thanks.

 

[vefatica]

If you say 'bdebugger batch.btm' without specifying a path to the batch file, only the current directory will be searched.

With or without a path specified for the batch file, IDE.EXE's current directory, and the directory in which the batch file is run, will be the current directory of the TCC which started IDE (the TCC to which you gave the 'bdebugger' command).

In your scenario, if TCC's current directory is c:\ then IDE's current directory will be c:\, and since no path was specified IDE will look for batch.btm in c:\.

 

[topherius]

Thank you for the reply. I'm not sure I'm following. In my scenario, my code is sitting in e:\code, and my TCC current working directory on the command line is also e:\code. If I type 'bdebugger batch.btm', it looks for the file in c:\, even though my current working directory is e:\code. To your point, the file will load if I use the literal path 'bdebugger e:\code\batch.btm' but even then, the file tries to execute in c:\ when I step into the code. I don't get it... guess I haven't had enough coffee tonight.

 

[Dan Glynhampton]

Thank you for the reply. I'm not sure I'm following. In my scenario, my code is sitting in e:\code, and my TCC current working directory on the command line is also e:\code. If I type 'bdebugger batch.btm', it looks for the file in c:\, even though my current working directory is e:\code. To your point, the file will load if I use the literal path 'bdebugger e:\code\batch.btm' but even then, the file tries to execute in c:\ when I step into the code. I don't get it... guess I haven't had enough coffee tonight.

Do you have a TCStart BTM file? If so do you execute a change to the root directory (c:\) in that file? If so I suspect that's the cause of the problem you are seeing. You could fix it with a conditional statement in your TCstart along the lines of:

if %_bdebugger EQ 0 *cdd c:\

You might also want to look at doing something similar for pipes (%_pipe) and transient shells (%_transient) to avoid much head scratching in those situations.

Dan

 

[topherius]

Brilliant. The issue was in tcstart, as you surmised. Now that I've fixed that, everything is working as I'd expect. Thanks a million.

 

[vefatica]

I just tested that and it seems like BAD behavior. Giving the BDEBUGGER command to TCC causes TCSTART.BTM to be executed even if a new instance of TCC is not being started. Maybe there's a good reason for it but I can't immediately think of one.

 

[Dan Glynhampton]

I just tested that and it seems like BAD behavior. Giving the BDEBUGGER command to TCC causes TCSTART.BTM to be executed even if a new instance of TCC is not being started. Maybe there's a good reason for it but I can't immediately think of one.

It's surmise and speculation on my part, but I think the debugger executes the batch file in a separate instance of TCC (probably hidden), and tcstart is executed in that instance (analogous to the situation where a pipe command starts an instance of TCC to receive the output from the pipe). Rex could give us chapter and verse on how it works, but he may not be inclined to if he considers it's JP Software's proprietary information.

Dan

 

[vefatica]

I think it works more like this.

IDE.EXE is, essentially, TCC (but without a console). If started from a console, it uses the console of its parent (via AttachConsole()). If not started from a console, it makes one (with AllocateConsole()). When you run a batch file in IDE, it's IDE that's running it. It's therefore no surprise that it (IDE.EXE) executes TCSTART when it starts (since you'd want batch files to behave normally).

Changing directories in TCSTART has never been advisable. It leads (as is obvious) to unexpected and unintended results. In the 20 years (or so) that I've been hanging around JPSoft forums (once upon a time, UseNet ... sigh!), problems stemming from that practice have arose quite regularly.

 

[Steve Fabian]

There is a long section about the issue of changing the current working directory in TCSTART in the HELP page for TCSTART. However, its heading Pipes, Transient Sessions / Processes, and TCSTART

"

 

[Steve Fabian]

The HELP topic TCSTART contains a long section on the topic of changing the CWD in TCSTART.However, its title Pipes, Transient Sessions / Processes, and TCSTART does not mention BDEBUGGER or IDE, nor - this is more important - directory changes. You need to actually read the text to find the same warning Vince and Dan mentioned above. It's probably still the best HELP for software I've seen.

 

[Dan Glynhampton]

I think it works more like this.

IDE.EXE is, essentially, TCC (but without a console). If started from a console, it uses the console of its parent (via AttachConsole()). If not started from a console, it makes one (with AllocateConsole()). When you run a batch file in IDE, it's IDE that's running it. It's therefore no surprise that it (IDE.EXE) executes TCSTART when it starts (since you'd want batch files to behave normally)..

That seems entirely plausible Vince, and your knowledge of the intricacies of Windows consoles is certainly much greater than mine :-)

Changing directories in TCSTART has never been advisable. It leads (as is obvious) to unexpected and unintended results. In the 20 years (or so) that I've been hanging around JPSoft forums (once upon a time, UseNet ... sigh!), problems stemming from that practice have arose quite regularly.

Yes, I recall replying to a thread a few months ago when someone had the same issue when using a pipe. However, as this thread shows, it's not always obvious when to expect tcstart to be executed, so I expect it's a topic that we'll return to again...

 

[vefatica]

The HELP topic TCSTART contains a long section on the topic of changing the CWD in TCSTART.However, its title Pipes, Transient Sessions / Processes, and TCSTART does not mention BDEBUGGER or IDE, nor - this is more important - directory changes. You need to actually read the text to find the same warning Vince and Dan mentioned above. It's probably still the best HELP for software I've seen.

Yup! And changing CWDs in TCSTART would also do in any TCCHere mechanism (on which I rely heavily).

 

[Steve Fabian]

Yup! And changing CWDs in TCSTART would also do in any TCCHere mechanism (on which I rely heavily).

That's another operation one can interfere with... but at least it is strictly under your control.

 

[vefatica]

How is it any more under my control that the other ill effects of changing directory in TCSTART?

 

[Steve Fabian]

I meant that you control what TCSTART does on your systems, side effects and all.