General steps to upgrade from 4NT3?

[NewViilageIT]

Hi all,

I'd like to upgrade from 4NT3 to TCC... finally. Then, I'll retire . I have a bunch of .bat files I've run with the 4NT3.

Can you please offer guidance or a general procedure I can follow to make the upgrade as painless as possible? e.g. commands that have been dropped or revised.

Or, ideally, is there nothing to do and I'm good to go, i.e. TCC 13 will run w/o a hitch?

Thank you for your help,

Chris

 

[rconn]

4NT 3 is about 15 years old, and was written for NT 3.5. I'm actually surprised it still works (unless you never upgraded your OS either?).

We haven't removed any commands (though some are deprecated and some are obsolete). Almost all of the commands have additional options, but provided you weren't using illegal syntax in your batch files that shouldn't be a problem. I.e., if you did something like "dir /s2" to display all of your subdirectories in two-column format (neglecting to insert the required / before the '2'), that will no longer work because /S2 now is a multicharacter switch meaning "only search subdirectories to a maximum of two levels deep".

The parser changed how it processes compound commands following an IF command (because CMD.EXE changed), but that will only affect you if you did things like:

if "%a" == "%b" echo foo & echo bar

and expected it to always echo "bar" regardless of the IF result. (CMD will *not* echo "bar" unless the IF test succeeds.) However, you can set an .INI option to restore the old (technically correct) behavior in TCC.

Also, if you pass a = as a batch file argument, CMD (and now TCC) will treat it as a whitespace character and remove it. You can also set an .INI option to use the old 4NT behavior of not considering a = as a delimiter.

I can't think of any other changes that should affect you. We did have a 4NT v5 user upgrade recently without any issues.

 

[thedave]

The parser changed how it processes compound commands following an IF command (because CMD.EXE changed), but that will only affect you if you did things like:

if "%a" == "%b" echo foo & echo bar

and expected it to always echo "bar" regardless of the IF result. (CMD will *not* echo "bar" unless the IF test succeeds.) However, you can set an .INI option to restore the old (technically correct) behavior in TCC.

This one tripped me up with a lot of old batch files due to the way FOR loops work. For example, FOR loops may fail unintuitively if you're expecting the old behaviour:

echo First a FOR loop: 
for %X in (1 a 2 b) do (
echos %x...
if %@isalpha[%x] == 1 echo Alpha!
if %@isdigit[%x] == 1 echo Digit!
)

echo Now a DO loop: 
do X in /L 1 a 2 b
echos %x...
if %@isalpha[%x] == 1 echo Alpha!
if %@isdigit[%x] == 1 echo Digit!
ENDDO

Apparently FOR loops are basically handled as one long line, whereas DO loops aren't, so the results look like this:

First a FOR loop:
1...a...Alpha!
2...b...Alpha!
Now a DO loop:
1...Digit!
a...Alpha!
2...Digit!
b...Alpha!​

Not a big deal to work around going forward, but if you've got a lot of FOR loops, you may need to set the compatibility switch or spend a bit of time switching to DO loops or IFF statements.

 

[NewViilageIT]

4NT 3 is about 15 years old, and was written for NT 3.5. I'm actually surprised it still works (unless you never upgraded your OS either?).

Yup. I'm running Win7 64. Still works.

...some are deprecated and some are obsolete...

Is there a link to these?

...If you pass a = as a batch file argument, CMD (and now TCC) will treat it as a whitespace character and remove it. You can also set an .INI option to use the old 4NT behavior of not considering a = as a delimiter.

I may have to use this option.

For example, FOR loops may fail unintuitively if you're expecting the old behaviour:

...and set this one, too.


Thanks for your quick response and help. Much appreciated.

Have a nice day.

 

[Rodolfo]

...
FOR loops may fail unintuitively if you're expecting the old behaviour:

echo First a FOR loop:
for %X in (1 a 2 b) do (
echos %x...
if %@isalpha[%x] == 1 echo Alpha!
if %@isdigit[%x] == 1 echo Digit!
)

...

On my system it works, with TCC 32 bit 13.04.52, I did a copy and paste from Your post:

[D:\IMMAGINI]for %X in (1 a 2 b) do (
More? echos %x...
More? if %@isalpha[%x] == 1 echo Alpha!
More? if %@isdigit[%x] == 1 echo Digit!
More? )
1...Digit!
a...Alpha!
2...Digit!
b...Alpha!

Regards

Rodolfo Giovanninetti

 

[Steve Fabian]

Here, too, with WinXP SP3 (32b) / TCC 13.04.52, whether I type the extended command in at the command prompt, or put it into a .BTM file, it displays 4 lines as in Rodolfo's report.

 

[rconn]

Is there a link to these?

Deprecated and/or obsolete:

DRAWBOX
DRAWHLINE
DRAWVLINE
EXCEPT
KEYS
LIST
MKLNK
VERIFY

All are still supported, but there are newer / better ways of doing them. (The DRAWxxx commands are leftovers from the 4DOS days. They still work in TCC & Take Command, if you choose the appropriate font.)

 

[mfarah]

Deprecated and/or obsolete:

DRAWBOX
DRAWHLINE
DRAWVLINE
EXCEPT
KEYS
LIST
MKLNK
VERIFY

All are still supported, but there are newer / better ways of doing them. (The DRAWxxx commands are leftovers from the 4DOS days. They still work in TCC & Take Command, if you choose the appropriate font.)

Er... what are better ways of doing EXCEPT and VERIFY?

 

[Charles Dye]

Er... what are better ways of doing EXCEPT and VERIFY?

Exclusion ranges are a better way of excluding files, at least as far as internal commands are concerned. EXCEPT is really only useful for external utilities.

As for VERIFY, I think that REM does much the same thing, only with more forgiving syntax.

 

[Steve Fabian]

EXCEPT: use exclusion range
VERIFY: in COPY and MOVE and SYNC, use the /V (verify) option - this is a superset of the old VERIFY command, which only verified that data was actually written, but not that it was written correctly; the /V option reads back from the disk and compares with the original. Even this might be imperfect with modern disk drives, which often have 8MB caches, and may read back from the cache instead of the physical drive (though there may be a low-level interface signal to force dumping the cache to disk before the read-back). There is no equivalent in WinNT+ to the old VERIFY in other instances.

 

[NewViilageIT]

On my system it works, with TCC 32 bit 13.04.52, I did a copy and paste from

Doesn't work for TCC 13.04.52 x64:

TCC  13.04.52 x64   Windows 7 [Version 6.1.7601]
Copyright 2012 JP Software Inc.  All Rights Reserved
Your evaluation period expires in 28 days.
You can buy Take Command at [URL]http://jpsoft.com[/URL]
[C:\Program Files\JPSoft\TCMD13x64]for %X in (1 a 2 b) do (
More? echos %x...
More? if [EMAIL]%@isalpha[%x[/EMAIL]] == 1 echo Alpha!
More? if [EMAIL]%@isdigit[%x[/EMAIL]] == 1 echo Digit!
More? )
1...a...Alpha!
2...b...Alpha!

 

[NewViilageIT]

Deprecated and/or obsolete:

DRAWBOX
DRAWHLINE
DRAWVLINE
EXCEPT
KEYS
LIST
MKLNK
VERIFY

All are still supported, but there are newer / better ways of doing them. (The DRAWxxx commands are leftovers from the 4DOS days. They still work in TCC & Take Command, if you choose the appropriate font.)

Thank you, Rexx!

 

[Rodolfo]

Doesn't work for TCC 13.04.52 x64:

...
[C:\Program Files\JPSoft\TCMD13x64]for %X in (1 a 2 b) do (
More? echos %x...
More? if [EMAIL]%@isalpha[%x[/EMAIL]] == 1 echo Alpha!
More? if [EMAIL]%@isdigit[%x[/EMAIL]] == 1 echo Digit!
More? )
1...a...Alpha!
2...b...Alpha!

What happens if You do some changes?
1) In the for loop, from "%X" to "%x", from uppercase to lowercase?
2) Change from "echos %x..." to "echo %x...": it seems to me that maybe in the for loop it still handles four different steps, but when there is a number neither isalpha nor isdigit are satisfied, and so with echos it continues on the same line. You must consider that Your example says 1...a..., and so there are dots twice, so in my opinion these lines are the result of two different echos, one for a digit variable not hadled by following %@is...
3) And if You add a line, just before the close parenthesis, that says "echo another step", for the same reason of 2.

Regards

Rodolfo Giovanninetti

 

[mathewsdw]

Guys, I don't really understand what the problem is here. The following works perfectly for me (TCC 13.03.48 Windows 7 [Version 6.1.7601]):

For %X in (1 a 2 b) Do (EchoS %X & If %@IsAlpha[%x] == 1 Echo  Alpha! & If %@IsDigit[%X] == 1 Echo  Digit!)

In case you for some reason don't completely believe me, here's the output (unmodified in any way) from the above:

1 Digit!
a Alpha!
2 Digit!
b Alpha!

I will note just to be complete that there is an extra space between the "Echo" commands and the words "Alpha!" and "Digit!".

 

[Rodolfo]

Guys, I don't really understand what the problem is here. The following works perfectly for me (TCC 13.03.48 Windows 7 [Version 6.1.7601]):

For %X in (1 a 2 b) Do (EchoS %X & If %@IsAlpha[%x] == 1 Echo  Alpha! & If %@IsDigit[%X] == 1 Echo  Digit!)

In case you for some reason don't completely believe me, here's the output (unmodified in any way) from the above:

1 Digit!
a Alpha!
2 Digit!
b Alpha!

I will note just to be complete that there is an extra space between the "Echo" commands and the words "Alpha!" and "Digit!".

The original code:

echo First a FOR loop:
for %X in (1 a 2 b) do (
echos %x...
if %@isalpha[%x] == 1 echo Alpha!
if %@isdigit[%x] == 1 echo Digit!
)

Maybe I did NOT understand what The Dave was saying.
I understood that he meant that "1 a 2 b" was considered as one single line.
Instead, now it seems to me that he meant that instructions inside the for loop are handled as a single line.
Rex, can You spot some light on this?
If You consider the same code but with the for loop as one single long line You get:

echo First a FOR loop:
for %X in (1 a 2 b) do (echos %x... if %@isalpha[%x] == 1 echo Alpha! if %@isdigit[%x] == 1 echo Digit!)

So the second if is a part inside the first if.
When the variable is 1 or 2, the isaplha is not satisfied, so the echo alpha is not executed, but it is NOT executed also the second if isdigit and it is NOT executed the echo digit.
When the variable is a or b, the first if isalpha is satisfied, and so the echo alpha is executed, whereas the second isdigit is NOT satisfied and the echo digit is NOT executed.
In Your example, mathewsdw, You use the "&" separator, so I believe that You change the semantic if the command.

Regards

Rodolfo Giovanninetti

 

[Charles Dye]

This one tripped me up with a lot of old batch files due to the way FOR loops work. For example, FOR loops may fail unintuitively if you're expecting the old behaviour:

echo First a FOR loop:
for %X in (1 a 2 b) do (
echos %x...
if %@isalpha[%x] == 1 echo Alpha!
if %@isdigit[%x] == 1 echo Digit!
)
 
echo Now a DO loop:
do X in /L 1 a 2 b
echos %x...
if %@isalpha[%x] == 1 echo Alpha!
if %@isdigit[%x] == 1 echo Digit!
ENDDO

Apparently FOR loops are basically handled as one long line, whereas DO loops aren't, so the results look like this:

It has nothing to do with FOR versus DO. The first example is treated as a single line because, well, it is a single line. That's how command groups work: what's inside the parentheses is reassembled into a single line. You'll get the same results in a DO/ENDDO block if you use a command group there. (And the DuplicateBugs directive will therefore apply.)

@echo off
setlocal
 
set SaveDB=%@option[DuplicateBugs]
 
option //DuplicateBugs=yes
 
echo.
echo Here is a DO loop containing a command group, with DuplicateBugs on:
 
do X in /L 1 a 2 b
    (
    echos %x...
    if %@isalpha[%x] == 1 echo Alpha!
    if %@isdigit[%x] == 1 echo Digit!
    )
enddo
 
option //DuplicateBugs=no
 
echo.
echo And here is the same exact DO loop, only with DuplicateBugs off:
 
do X in /L 1 a 2 b
    (
    echos %x...
    if %@isalpha[%x] == 1 echo Alpha!
    if %@isdigit[%x] == 1 echo Digit!
    )
enddo
 
option //DuplicateBugs=%SaveDB
endlocal

 

[drwtsn32]

Guys, I don't really understand what the problem is here. The following works perfectly for me (TCC 13.03.48 Windows 7 [Version 6.1.7601]):

For %X in (1 a 2 b) Do (EchoS %X & If %@IsAlpha[%x] == 1 Echo  Alpha! & If %@IsDigit[%X] == 1 Echo  Digit!)

In case you for some reason don't completely believe me, here's the output (unmodified in any way) from the above:

1 Digit!
a Alpha!
2 Digit!
b Alpha!

I will note just to be complete that there is an extra space between the "Echo" commands and the words "Alpha!" and "Digit!".

The results you get in TCMD from this test are entirely dependent upon if you enabled the "Duplicate CMD.EXE bugs" option or not. You have that option unchecked.

 

[drwtsn32]

The results you get in TCMD from this test are entirely dependent upon if you enabled the "Duplicate CMD.EXE bugs" option or not. You have that option unchecked.

That being said, I don't actually see CMD.EXE behaving this way with a for loop and multiple IFs:

for %x in (1 a 2 b) do (
  echo %x...
  if "%x" == "1" echo 1!
  if "%x" == "a" echo a!
  if "%x" == "2" echo 2!
  if "%x" == "b" echo b!
)

This works as you would intuitively expect...

 

[mathewsdw]

Rod, I clearly don't understand what you are saying because my example works correctly whether or not "Duplicate CMD.EXE bugs" is checked or not. (I tried it 3 or 4 times both with it checked and with it unchecked and it always performed as I would have hoped. I will also add that, given that I have used TCC(/4DOS) since Windows 3.1, I would have no reason whatsoever to check that box in the first place.)

And your code doesn't work (and I could find no variation of it that worked) in my cmd.exe. Specifically I always get the error message "x was unexpected at this time.". Final variations: batch files containing just "For x In (1 a 2 b) do (" and "For %x In (1 a 2 b) do (" both followed by a line with just a closing parenthesis). I have no clue as to why this should be the case, but it is the case. (Microsoft Windows [Version 6.1.7601])

Yet another mystery, I suppose.

- Dan

 

[Charles Dye]

That being said, I don't actually see CMD.EXE behaving this way with a for loop and multiple IFs:

Try it on a single line, with ampersands between the IF statements.

 

[Charles Dye]

Rod, I clearly don't understand what you are saying because my example works correctly whether or not "Duplicate CMD.EXE bugs" is checked or not. (I tried it 3 or 4 times both with it checked and with it unchecked and it always performed as I would have hoped.

Let me guess: Using the Options / Configure TCC dialog?

 

[mathewsdw]

I would have to say yes given that I used the "options/configure TCC..." dialog. (And if that works differently than the option command then that is a bug.)

 

[Charles Dye]

The OPTION command changes settings for the current shell, and also writes them to the .INI file. The Options / Configure TCC dialog only writes to the .INI file, effectively settings defaults for future instances of TCC.

 

[mathewsdw]

Boy, Charles, I had no clue! I would have (and did!) assume otherwise. Now that I know that after I hit the "send" button on this I'll experiment just a little bit more (just out of curiosity more than anything else). I do consider this to be a bit of a bug. - Dan

 

[mathewsdw]

Charles, an update. I can't figure out what the name of "Duplicate cmd.exe bugs" is re. the option command;
everything I try (double quotes, spaces, no spaces, whatever) just gives me "TCC: Unknown option name 'xxxx'" and I haven't been able to find out how to do this from the command line in the help.

 

[Charles Dye]

Charles, an update. I can't figure out what the name of "Duplicate cmd.exe bugs" is re. the option command;
everything I try (double quotes, spaces, no spaces, whatever) just gives me "TCC: Unknown option name 'xxxx'" and I haven't been able to find out how to do this from the command line in the help.

DuplicateBugs, as in OPTION //DUPLICATEBUGS=NO. Or just type OPTION with no args to use the dialog; first tab, rightmost column, second one down.

(You can find many directive names by reading the .INI file, e.g. with LIST "%_ININAME" .)

 

[mathewsdw]

Charles, as I thought you had indicated above and seemed to be the case options set using the dialog do not actually take effect until the next time you start TCC. However, reading the .ini file (if I can remember where it is and/or how to find out where it is!;)) is and would have been a very good idea! Thank you! - Dan

 

[mathewsdw]

Immediate update: I saw the "LIST '%_ININAME'" in your posting just after I hit the send button on the previous. Blindness hits again!

 

[Charles Dye]

Dan, I think the fact that you're missing is that there are two dialogs. Or rather, one dialog invoked two different ways. If you use the Options / Configure TCC menu item, you get a "TCC Properties" dialog which only changes the .INI file. If you use the OPTION command, you get the same dialog, but it changes both the current shell's behavior and the .INI file.

The bottom line is that you almost always want the OPTION command.

 

[mathewsdw]

Thank you yet again, Charles. I would have never guessed. (And BTW, "Duplicatebugs" has the effect as described. Thank God I have no reason to duplicate cmd.exe bugs!)