0

I found a problem with some batch files not written by me when executed in TCC/LE, while the same ones run flawlessly with CMD.EXE (Windows XP up to Windows 11 versions). Maybe the problem is very silly, but I can't spot it, even if I localized it to a handful of lines:

for /F %%i in (list.txt) do (
  echo ----- Process 1: %%i
  if errorlevel 1 goto Error
  echo ----- Process 2: %%i
  if errorlevel 1 goto Error
  echo ----- End with %%i
  )
goto End
:Error
echo Error!
:End

With TCC/LE version 6.3.22621 it never gets to "Process 2" text, while with CMD it executes the whole loop.

The text file list.txt contains in my sample just

abc
def

The culprit seems to be the "if errorlevel..." line, which breaks the loop before the end (though not going to the Error label).

Can anyone help me?

Here's the transcript with both command line interfaces:

[C:\Test]ver /r

TCC LE  14.00.9 x64   Windows 10 [Version 6.3.22621]
TCC LE Build 9   Windows 10 Build 22621

[C:\Test]verif.bat
for /F %%i in (list.txt) do ( echo ----- Process 1: %%i & if errorlevel 1 goto Error & echo ----- Process 2: %%i & if errorlevel 1 goto Error & echo ----- End with %%i )
----- Process 1: abc
----- Process 1: def
goto End

[C:\Test]cmd
Microsoft Windows [Versione 10.0.22621.963]
(c) Microsoft Corporation. Tutti i diritti riservati.

C:\Test>verif.bat

C:\Test>for /F %i in (list.txt) do (
echo ----- Process 1: %i
 if errorlevel 1 goto Error
 echo ----- Process 2: %i
 if errorlevel 1 goto Error
 echo ----- End with %i
)

C:\Test>(
echo ----- Process 1: abc
 if errorlevel 1 goto Error
 echo ----- Process 2: abc
 if errorlevel 1 goto Error
 echo ----- End with abc
)
----- Process 1: abc
----- Process 2: abc
----- End with abc

C:\Test>(
echo ----- Process 1: def
 if errorlevel 1 goto Error
 echo ----- Process 2: def
 if errorlevel 1 goto Error
 echo ----- End with def
)
----- Process 1: def
----- Process 2: def
----- End with def

C:\Test>goto End

C:\Test>
LuC
  • 347
  • 2
  • 10

1 Answers1

0

Well, I managed to resolve it, quite unexpectedly...

As documented on JPSoftware FAQ on IF commands

at some time in the past CMD.EXE introduced a bug on IF commands, and the Microsoft batch files were using that bug to work (...) so they introduced an option to be "buggy as CMD".

That option can be disabled from the TCC option window, called with OPTION from the command line and disabling the duplication of CMD bugs... that eventually have been fixed in the recent command processors, as even CMD.EXE works "without bugs" on IF!

LuC
  • 347
  • 2
  • 10
  • 1
    The statement, "Microsoft was distributing a number of batch files that would not work with 4NT or Take Command.", should be read as, "my software is incorrectly replacing line endings with `&` to make compound statements without parentheses, and then trying to blame the originators who didn't do that". Your issue is simply that you were trying to use a (relatively) correctly written batch file in software which changes it, unless configured not to. – Compo Jan 02 '23 at 14:54
  • @Compo that doesn't look to me like the case: the single '&' seems to not have had side effects in this case. Moreover, the single '&' works also with CMD's recent versions... – LuC Jan 03 '23 at 23:09