IF command problem in tcexit.btm

[Bob Chapman]

TCC 25.00.23 x64 Windows 10 [Version 10.0.18362.476]

For the following tcexit.btm

:: tcexit.btm
@ECHO OFF
echo Pipe %_pipe Trans %_transient > c:\Users\Public\test_output\1before_if
if %_pipe != "0" .or. %_transient != "0" quit
echo Pipe %_pipe Trans %_transient > c:\Users\Public\test_output\2after_if

If I exit an instance of TakeCommand by executing EXIT at the command prompt of the single remaining tab the following output occurs:​

 Directory of  C:\Users\Public\test_output\*

11/14/2019  20:03              16  1before_if
11/14/2019  20:03              16  2after_if
                  32 bytes in 2 files and 0 dirs

 >cat 1before_if
Pipe 0 Trans 0
 >cat 2after_if
Pipe 0 Trans 0

However, if I exit by clicking the X button window control or the X Close window option on the Taskbar icon or selecting the Menu Bar HOME EXIT option the following output occurs:​

 Directory of  C:\Users\Public\test_output\*

11/14/2019  20:46              16  1before_if
                  16 bytes in 1 file and 0 dirs

 >cat 1before_if
Pipe 0 Trans 0

Why isn't the second ECHO command executed for these exit cases??? ​

 

[Charles Dye]

I don't see how that final line could ever be executed. You're quoting the zeroes but not the variables; the condition should never be true.

 

[vefatica]

With a similar TCEXIT

set test=%[_PIPE]%[_TRANSIENT]
echo before: %_pid %test > v:\tcexit.log
if "%test" != "00" quit
echo after: %_pid %test >> v:\tcexit.log

I get both log entries (before/after) regardless of how I terminate TCC ... the EXIT command, X the console, X the TCMD tab, X TCMD, choose Home\Exit in TCMD.

 

[Bob Chapman]

Perhaps if I had posted the actual - as executed tcexit.btm it would make more sense Guess I should have waited until morning to post the question! ​

:: tcexit.btm
@ECHO OFF
echo Pipe %_pipe Trans %_transient > c:\Users\Public\test_output\1before_if
if %_pipe != 0 .or. %_transient != 0 quit
echo Pipe %_pipe Trans %_transient > c:\Users\Public\test_output\2after_if

Note: The actual IF statement is identical to the example found in the HELP for TCSTART and TCEXIT.​

So -- Why isn't the second ECHO command executed for all of the exit cases??? ​

 

[Charles Dye]

Okay. I can replicate this.

Here's a version that works as you would expect:

@ECHO OFF
echo Pipe %_pipe Trans %_transient > c:\Users\Public\test_output\1before_if
if "%_pipe" != "0" .or. "%_transient" != "0" quit
echo Pipe %_pipe Trans %_transient > c:\Users\Public\test_output\2after_if

And here is a version which displays the same behavior, but without the IF command:

@ECHO OFF
echo Pipe %_pipe Trans %_transient > c:\Users\Public\test_output\1before_if
echo %@eval[6 * 9]
echo Pipe %_pipe Trans %_transient > c:\Users\Public\test_output\2after_if

My wild-assed guess: When you exit by closing the console — the big red X — Windows kills the associated program very quickly, a fraction of a second. But when you use the EXIT command, there is no time limit; TCC can take as long as it wants. And I suspect that the parsing of numbers is pretty slow, due to the big-numbers support Rex added a few versions back.

 

[Bob Chapman]

Okay. I can replicate this.
, , , ,

Thanks for taking the time to confirm my somewhat flawed report. If your surmise is correct then this really impairs the utility of tcexit.btm at least for my usage cases [and IMNSHO]. I don't want to count on winning a race against the OS -- we all know just who is going to win! ​

I only noticed this behavior after upgrading to TakeCommand 25.00.23 x64 from 24.02.51 x64 and have no idea just how long this has been a feature? ​

 

[Charles Dye]

Thanks for taking the time to confirm my somewhat flawed report. If your surmise is correct then this really impairs the utility of tcexit.btm at least for my usage cases [and IMNSHO]. I don't want to count on winning a race against the OS -- we all know just who is going to win!

I only noticed this behavior after upgrading to TakeCommand 25.00.23 x64 from 24.02.51 x64 and have no idea just how long this has been a feature?

Don't know; I've never noticed it. And my guess as to what's going on could be completely wrong. Hoping to hear from Rex on this one.

 

[vefatica]

Something peculiar is going on. With a simple PAUSE in TCEXIT, the TCC process terminates a full 5 seconds after any attempt to terminate (EXIT, X-ing the console, X-ing a TCMD tab, X-ing TCMD itself). So Windows is giving it the 5 (as advertised) seconds.

That all changes if, before the PAUSE, I put an "ECHO %@EVAL[]" statement (like Charles) ... then X-ing the console is immediate. It's not the time to execute the @EVAL ... "DELAY 1" does not have that effect.

 

[rconn]

An interesting Windows bug / undocumented behavior.

Windows is throwing an exception (in ntdll, not in the TCC code) if an EnterCriticalSection API call is made during the WM_QUERYENDSESSION processing. The math library is calling EnterCriticalSection to allow multithreading, so disabling the critical section calls will break other (more obvious) things.

I can add a kludge to turn off multithreading during shutdown (which *probably* won't break too many things).

 

[Bob Chapman]

I can add a kludge to turn off multithreading during shutdown . . .

May we expect that to happen or will the Take Command/TCC HELP section TCC Termination Program be updated to clearly identify the only(?) case where the TCEXIT program can be expected to run to a normal exit?

Update: Of course Rex fixed this -- perhaps before I posted the comment. Next time I'll check updates before posting!