1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

General steps to upgrade from 4NT3?

Discussion in 'Support' started by NewViilageIT, Mar 8, 2012.

  1. NewViilageIT

    Joined:
    Mar 7, 2012
    Messages:
    4
    Likes Received:
    0
    Hi all,

    I'd like to upgrade from 4NT3 to TCC... finally. Then, I'll retire :cool:. 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
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,732
    Likes Received:
    81
    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.
     
    NewViilageIT likes this.
  3. thedave

    Joined:
    Nov 13, 2008
    Messages:
    254
    Likes Received:
    2
    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:

    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!
    )
    
    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 likes this.
  4. NewViilageIT

    Joined:
    Mar 7, 2012
    Messages:
    4
    Likes Received:
    0
    Yup. I'm running Win7 64. Still works.

    Is there a link to these?

    I may have to use this option.

    ...and set this one, too.


    Thanks for your quick response and help. Much appreciated.

    Have a nice day.
     
  5. Rodolfo

    Joined:
    May 20, 2009
    Messages:
    213
    Likes Received:
    0
    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
     
  6. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    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.
     
  7. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,732
    Likes Received:
    81
    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.)
     
  8. mfarah

    Joined:
    Nov 2, 2009
    Messages:
    226
    Likes Received:
    5
    Er... what are better ways of doing EXCEPT and VERIFY?
     
  9. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,279
    Likes Received:
    38
    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.
     
  10. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,523
    Likes Received:
    4
    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.
     
  11. NewViilageIT

    Joined:
    Mar 7, 2012
    Messages:
    4
    Likes Received:
    0
    Doesn't work for TCC 13.04.52 x64:
    Code:
    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!
    
     
  12. NewViilageIT

    Joined:
    Mar 7, 2012
    Messages:
    4
    Likes Received:
    0
    :cool: Thank you, Rexx!
     
  13. Rodolfo

    Joined:
    May 20, 2009
    Messages:
    213
    Likes Received:
    0
    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
     
  14. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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]):
    Code:
    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:
    Code:
    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!".
     
  15. Rodolfo

    Joined:
    May 20, 2009
    Messages:
    213
    Likes Received:
    0
    The original code:
    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:
    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!)
    
    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
     
  16. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,279
    Likes Received:
    38
    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.)

    Code:
    @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
    
     
  17. Rod Savard

    Joined:
    May 26, 2008
    Messages:
    481
    Likes Received:
    3
    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.
     
  18. Rod Savard

    Joined:
    May 26, 2008
    Messages:
    481
    Likes Received:
    3
    That being said, I don't actually see CMD.EXE behaving this way with a for loop and multiple IFs:

    Code:
    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...
     
  19. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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
     
  20. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,279
    Likes Received:
    38
    Try it on a single line, with ampersands between the IF statements.
     
  21. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,279
    Likes Received:
    38
    Let me guess: Using the Options / Configure TCC dialog?
     
  22. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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.)
     
  23. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,279
    Likes Received:
    38
    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.
     
  24. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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
     
  25. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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.
     
  26. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,279
    Likes Received:
    38
    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" .)
     
  27. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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
     
  28. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    Immediate update: I saw the "LIST '%_ININAME'" in your posting just after I hit the send button on the previous. Blindness hits again!
     
  29. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,279
    Likes Received:
    38
    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.
     
  30. mathewsdw

    Joined:
    May 24, 2010
    Messages:
    855
    Likes Received:
    0
    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!)
     

Share This Page