batch file ending early

[fpefpe]

I am expanding over 100 rar archive file so I have a batch file to call rar.exe for each files to expand. As it turns out about half way processing the files one of the rar file failed the checksum processing that rar performs — rar issue a rc of 3, and seems to end the bat file but there are more files to unrar — is there a signal that rar could be generating to cause the bat file to break? Thanks

 

[Charles G]

FWIW - maybe post the BTM/BAT/CMD file..... I did find the RC at List of WinRAR exit codes

 

[fpefpe]

FWIW - maybe post the BTM/BAT/CMD file..... I did find the RC at List of WinRAR exit codes

Hello --- thx for the reply --- here is the bat file --- the first rar file fails and stops the bat file

 

[vefatica]

I wonder if WINRAR generates some sort of signal (CTRL_C_EVENT?). Try putting "on break echos > nul" at the beginning of your BTM file.

 

[Charles G]

slightly modified......

 

[fpefpe]

I wonder if WINRAR generates some sort of signal (CTRL_C_EVENT?). Try putting "on break echos > nul" at the beginning of your BTM file.

Hello --- it seems that your suggestion seemed to work -- thanks

 

[fpefpe]

slightly modified......

yes -- thx for the update too

 

[nikbackm]

I had a similar problem, but for ROBOCOPY instead of RAR.

I called ROBOCOPY via an environment variable like:

%robocopyvar_with_params%

This sometimes caused the batch file to just stop prematurely.

Problems went away when I replaced that line with:

echo %@exec[%robocopyvar_with_params%]

Could save the exec result to another variable instead of echo:ing it I guess, but this worked for me.

Like your batch file mine also have a gosub containing the via variable execution and that was called many times.

 

[vefatica]

Hello --- it seems that your suggestion seemed to work -- thanks

When it was terminating early, did you see any indication of a signal ... like "^C"?

 

[fpefpe]

I had a similar problem, but for ROBOCOPY instead of RAR.

I called ROBOCOPY via an environment variable like:

%robocopyvar_with_params%

This sometimes caused the batch file to just stop prematurely.

Problems went away when I replaced that line with:

echo %@exec[%robocopyvar_with_params%]

Could save the exec result to another variable instead of echo:ing it I guess, but this worked for me.

Like your batch file mine also have a gosub containing the via variable execution and that was called many times.

Hello --- Thanks for the tip ---

 

[rconn]

There is one case where TCC will terminate the batch file (and potentially itself). If an external application returns a 3 for the result, TCC will terminate.

Like most seemingly goofy behavior, this is for compatibility with CMD.

 

[fpefpe]

There is one case where TCC will terminate the batch file (and potentially itself). If an external application returns a 3 for the result, TCC will terminate.

Like most seemingly goofy behavior, this is for compatibility with CMD.

There is one case where TCC will terminate the batch file (and potentially itself). If an external application returns a 3 for the result, TCC will terminate.

Like most seemingly goofy behavior, this is for compatibility with CMD.

wow -- yes its goofy -- is there a global/local setting to not comply with the goofy que

 

[Charles Dye]

There is one case where TCC will terminate the batch file (and potentially itself). If an external application returns a 3 for the result, TCC will terminate.
Like most seemingly goofy behavior, this is for compatibility with CMD.

Is there a way to override this goofy CMD compatibility behavior?

 

[vefatica]

There is one case where TCC will terminate the batch file (and potentially itself). If an external application returns a 3 for the result, TCC will terminate.

Like most seemingly goofy behavior, this is for compatibility with CMD.

Would you explain further?

I just built this.

INT wmain (INT argc, LPWSTR *argv)
{
    return 3;
}

and ran it from command line/BAT/BTM in TCC and CMD. Nothing odd happened.

p:\hello\x64\release> type 3.bat
@echo off
p:\hello\x64\release\hello.exe
echo hello.exe returned %errorlevel%
echo I'm still going!
pause

p:\hello\x64\release> cmd
Microsoft Windows [Version 10.0.18363.719]
(c) 2019 Microsoft Corporation. All rights reserved.

P:\Hello\x64\Release> 3.bat
hello.exe returned 3
I'm still going!
Press any key to continue . . .

P:\Hello\x64\Release>

 

[evensenm]

Would you explain further?

I just built this.

INT wmain (INT argc, LPWSTR *argv)
{
    return 3;
}

and ran it from command line/BAT/BTM in TCC and CMD. Nothing odd happened.

p:\hello\x64\release> type 3.bat
@echo off
p:\hello\x64\release\hello.exe
echo hello.exe returned %errorlevel%
echo I'm still going!
pause

p:\hello\x64\release> cmd
Microsoft Windows [Version 10.0.18363.719]
(c) 2019 Microsoft Corporation. All rights reserved.

P:\Hello\x64\Release> 3.bat
hello.exe returned 3
I'm still going!
Press any key to continue . . .

P:\Hello\x64\Release>

Same thing here.....

D:\Users\Mark\Documents\test 4>type zzz.bat
@echo off
cmd /k "exit 3"
echo Return code was %?
echo Return code was also %errorlevel%
echo %0 is still alive!!!

D:\Users\Mark\Documents\test 4>

Under TCC:

D:\Users\Mark\Documents\test 4>zzz
Return code was 3
Return code was also 3
zzz is still alive!!!

D:\Users\Mark\Documents\test 4>

Under CMD:

d:\Users\Mark\Documents\test 4>zzz
Return code was ?
Return code was also 3
zzz is still alive!!!

d:\Users\Mark\Documents\test 4>

This is with:

TCC

D:\Users\Mark\Documents\test 4>ver

TCC  24.02.51 x64   Windows 10 [Version 10.0.18363.476]

D:\Users\Mark\Documents\test 4>

and

CMD

d:\Users\Mark\Documents\test 4>ver

Microsoft Windows [Version 10.0.18363.476]

d:\Users\Mark\Documents\test 4>

Note that "cmd /k" tells CMD to stay open after running the command, but the command "exit 3" itself tells CMD to exit with an exit code of 3.

 

[nikbackm]

@evensenm

I modified your batch file a little:

@echo off

gosub test %1
gosub test %1

quit

:test [rc]
cmd /k "exit %rc%"
echo Return code was %?
echo Return code was also %errorlevel%
echo %0 is still alive!!!
return

Running it:

C:\user\test>zzzz 1
Return code was 1
Return code was also 1
zzzz is still alive!!!
Return code was 1
Return code was also 1
zzzz is still alive!!!

C:\user\test>zzzz 3
Return code was 3
Return code was also 3
zzzz is still alive!!!

C:\user\test>zzzz 4
Return code was 4
Return code was also 4
zzzz is still alive!!!
Return code was 4
Return code was also 4
zzzz is still alive!!!

I am using:

TCC 20.11.46 x64 Windows 10 [Version 6.3.16299]

 

[AnrDaemon]

Can still reproduce it with TCC-RT 25. >.< Weird.
It's even MORE weird since it crashes even parent TCC process.
Any external program that return with code 3 will crash entire TCC stack when used right before "RETURN" statement, even if there's a number of internal commands called in between. Calling any other external command that return with a different exit code before "RETURN" (I've used cygwin's `sleep` utility to have a few seconds to look at the process tree before it all dies) will suppress the effect.
Test setup TCC crash on return from subroutine call

 

[AnrDaemon]

Workaround is to use CMD style call.

@ECHO OFF

CALL :test %~1
ECHO %~1:Ok

EXIT /B

:test
"%SystemRoot%\System32\cmd" /S /K "EXIT %~1"
GOTO :EOF

 

[AnrDaemon]

Bump.