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

TCMD does not get same result as cmd.exe

Discussion in 'Support' started by G.Sande, Oct 20, 2011.

  1. G.Sande

    Joined:
    Oct 20, 2011
    Messages:
    9
    Likes Received:
    0
    I have been trying to use the Intel Parallel Studio from the command line (and avoid MS Visual Studio xxxxx). It requires the execution of a batch file
    to set up multiple environment variables depending upon the target architecture and which version of VS is installed, etc. All too common.

    Under cmd.exe it works as the Intel folks intend. They must have used it for their development. But cmd.exe is so friendly I have used JPSoft stuff for
    a long time.

    Under TC13 I get a "unknown command amd64" because there is a line which looks like "call %xx% %yy%" where xx is null and yy is amd64 so the error
    message makes sense for that line. But why is xx null? It seems cmd.exe
    is able to set xx but TC13 skips that. Aren't things supposed to be
    compatible?

    Under TC10 (pain in the you know where to switch back and forth) I get an
    "invalid argument at" with none of the apparent blanks filed in. Even less
    useful than TC13.

    What magic switches are needed to get TC to produce the same execution
    of the Intel batch files?
     
  2. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    From: G.Sande
    | What magic switches are needed to get TC to produce the same execution
    | of the Intel batch files?

    Probably the option to emulate CMD bugs!

    Without showing the Intel-supplied batch file we have no idea what may cause the problems you observed.
    --
    Steve
     
  3. Charles G

    Joined:
    Apr 2, 2011
    Messages:
    1,022
    Likes Received:
    0
    I would believe what you need to enable are: (from Option, startup tab)

    - Duplicate CMD.EXE bugs
    - CMD.EXE delayed expansion (!var!)

    both need to be checked.
    ----- Original Message -----
    From: G.Sande
    To: CSGalloway@nc.rr.com
    Sent: Thursday, October 20, 2011 03:27 PM
    Subject: [Support-t-3304] TCMD does not get same result as cmd.exe


    I have been trying to use the Intel Parallel Studio from the command line (and avoid MS Visual Studio xxxxx). It requires the execution of a batch file
    to set up multiple environment variables depending upon the target architecture and which version of VS is installed, etc. All too common.

    [snip]

    What magic switches are needed to get TC to produce the same execution
    of the Intel batch files?
     
  4. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,190
    Likes Received:
    11
    Try turning on "Duplicate CMD.EXE
    bugs" from the TCC option dialog and see if that makes a difference.
    You will have to restart TCC to make the change take effect.

    If not, then attach the batch file and
    we'll take a gander and figure it out.

    -Scott


    G.Sande <> wrote on 10/20/2011
    03:27:46 PM:




    is a line

    is amd64


    get an

    in. Even less

     
  5. Charles G

    Joined:
    Apr 2, 2011
    Messages:
    1,022
    Likes Received:
    0
    What options in the option dialog aren't read unless TCC is restarted? I don't see that in the docs....
    ----- Original Message -----
    From: Charles G
    To: CSGalloway@nc.rr.com
    Sent: Thursday, October 20, 2011 03:56 PM
    Subject: RE: [Support-t-3304] TCMD does not get same result as cmd.exe


    I would believe what you need to enable are: (from Option, startup tab)

    - Duplicate CMD.EXE bugs
    - CMD.EXE delayed expansion (!var!)

    both need to be checked.
    ----- Original Message -----
    From: G.Sande
    To: CSGalloway@nc.rr.com
    Sent: Thursday, October 20, 2011 03:27 PM
    Subject: [Support-t-3304] TCMD does not get same result as cmd.exe


    I have been trying to use the Intel Parallel Studio from the command line (and avoid MS Visual Studio xxxxx). It requires the execution of a batch file
    to set up multiple environment variables depending upon the target architecture and which version of VS is installed, etc. All too common.

    [snip]

    What magic switches are needed to get TC to produce the same execution
    of the Intel batch files?
     
  6. G.Sande

    Joined:
    Oct 20, 2011
    Messages:
    9
    Likes Received:
    0
    TCStart.bat calls ifortvars.bat which calls compilervars_arch.bat.
    The error message gives unknown command amd64 at line 215.
     

    Attached Files:

  7. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,307
    Likes Received:
    39
    I only took a brief glance at it, but I see a whole lot of ampersands after IFs. Did you check "Duplicate CMD.EXE bugs", as Steve suggested?
     
  8. samintz

    samintz Scott Mintz

    Joined:
    May 20, 2008
    Messages:
    1,190
    Likes Received:
    11
    With "Duplicate CMD.EXE bugs" turned on, the attached batch files ran just
    fine for me.

    The culprit is the IF statement.

    For example, the batch files contain many statements like:
    if /i "%1"=="vs2010" (set TARGET_VS=vs2010) & (set
    WIN_TITLE_VS=Visual Studio 2010) & shift & goto ParseArgs


    When an IF test fails, the remainder of the command is discarded. Whether
    TCC continues with the next command on the line, or discards the rest of
    the line and goes to the next line is dependent upon the Duplicate CMD
    Bugs configuration option. CMD will discard all remaining commands on the
    line when an IF test fails, including those after a command separator or
    pipe character.

    For example, if Duplicate CMD Bugs is enabled, the following command will
    display nothing, because the second ECHO command is discarded along with
    the first when the condition fails. If Duplicate CMD Bugs is disabled, it
    will display "hello":




    [c:\] if 1 == 2 echo Wrong! & echo hello


    -Scott




    Quote:
    Originally Posted by Steve Fabian
    From: G.Sande
    | What magic switches are needed to get TC to produce the same execution
    | of the Intel batch files?

    Probably the option to emulate CMD bugs!

    Without showing the Intel-supplied batch file we have no idea what may
    cause the problems you observed.
    --
    Steve
    TCStart.bat calls ifortvars.bat which calls compilervars_arch.bat.
    The error message gives unknown command amd64 at line 215.

    Attached to this message is TCStart.bat

    Attached to this message is ifortvars.bat

    Attached to this message is compilervars_arch.bat
     
  9. G.Sande

    Joined:
    Oct 20, 2011
    Messages:
    9
    Likes Received:
    0
    Reloaded TC13. The options are under TCC options. Duplicate cmd.exe bugs seems on be default. This on a Windows 7 (64-bit).

    With both options off the top ifortvars.bat yields a usage diagnostic so does not get very far.

    With either just cmd.exe bugs or both options set the result is the unknown command amd64 at line 215 resulting from the null variable problem.

    So the Intel folks seem to have used some new improved bug in cmd.exe but
    it leaves me with either putting up with cmd.exe or fighting with MSVS and
    tossing the command scripts that I have been using for quite a while. I do not
    relish the notion of having to use yet another IDE to test portability to Windows.
     
  10. David Marcus

    Joined:
    Jun 4, 2008
    Messages:
    648
    Likes Received:
    1
    Change "echo off" to "echo on" in the files and try running under both cmd and TCC to see what the difference is.
     
  11. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    Your batch files work perfectly here; %MSVS_VAR_SCRIPT% is set appropriately
    and vcvarsall.bat is called with the correct arguments.

    I suspect your environment isn't the same in your CMD and TCC sessions. In
    particular, look for the VSxxCOMNTOOLS variable in your TCC session (replace
    "xx" with your VS version). If that isn't set and pointing to the right
    directory then your MSVS_VAR_SCRIPT variable will never be set.
    Alternately, try setting the VS version in the incoming arguments (i.e.,
    "ifortvars.bat vs2010 intel64").
     
  12. G.Sande

    Joined:
    Oct 20, 2011
    Messages:
    9
    Likes Received:
    0
    Capturing the output from was straightforward. For TCMD it required recalling
    how to capture both output and errors. I removed the TCstart to keep things
    simple.

    Not much similarity visually as cmd.exe substitutes the values for variables
    while TCMD gives the variables. Anyway the two results are there.
     

    Attached Files:

  13. David Marcus

    Joined:
    Jun 4, 2008
    Messages:
    648
    Likes Received:
    1
    You need to figure out why the variable isn't being set. Put in echo statements or use the debugger to find what the difference is.

    Do the files just set up some environment variables? You could figure out what is set on your machine by running under cmd and then doing "set" and then create a bat file for TCC that just sets those variables.
     
  14. G.Sande

    Joined:
    Oct 20, 2011
    Messages:
    9
    Likes Received:
    0
    >> You need to figure out why the variable isn't being set.

    That is why I posted the fact that the same batch file executed by cmd.exe
    and TCMD yield different results. One of the two has an undocumented feature
    (aka bug) that goes beyond the TCMD options of duplicating the cmd.exe bugs.

    If you would like I can capture the environment going into the batch files. My
    naive take was that support was supposed to provide assistance in explaining
    why supposedly compatible TCMD does not replicate the results of the setup
    batch file supplied by Intel.
     
  15. David Marcus

    Joined:
    Jun 4, 2008
    Messages:
    648
    Likes Received:
    1
    Rex did try your bat files and they worked on his computer. He suggested what you should do next. Did you do what Rex suggested? It does appear that your cmd and TCC sessions are not starting with the same environments.
     
  16. G.Sande

    Joined:
    Oct 20, 2011
    Messages:
    9
    Likes Received:
    0
    I have been dealing with the responses that have arrived by email.

    What is it that an I supposed to be doing?

    The cmd.exe and TCMD are executed one after the other with no attempt
    to change the environment. If the two programs think the environment has changed then their dealing with the environment is not done in a compatible
    fashion.
     
  17. David Marcus

    Joined:
    Jun 4, 2008
    Messages:
    648
    Likes Received:
    1
    If you didn't get Rex's response, then please visit the forum website and read it. Rex actually owns JP Software. The rest of us are customers.

    How are you "executing" (starting) them?

    I don't think JP Software ever claimed that cmd and TCC were identical. Considering the huge number of additional features TCC has, they are remarkably compatible.
     
  18. G.Sande

    Joined:
    Oct 20, 2011
    Messages:
    9
    Likes Received:
    0
    From the manual "Take Command Language - A mature scripting language based on and compatible with CMD, but massively enhanced."

    Perhaps there is some other definition of compatible. Matching undocumented
    features is sometimes a moving target. I had expected there might be
    switches, but those seem to only solve some problems. I notice that the Intel
    stuff fills the environment with lots of text. In the bad old days there were
    limits on how much was possible. I have recently had to file a bug report on
    a compiler with a finite table which I overflowed when I asked for subscript
    checking while trying to localize a different bug in that compiler. If TCMD
    had trouble with too much text in the environment tables that would not be
    very surprising. But it is not my job to debug it, just to report apparent bugs.
     
  19. G.Sande

    Joined:
    Oct 20, 2011
    Messages:
    9
    Likes Received:
    0
    The cmd.exe and TCMD runs were done one after the other with no known
    changes to anything between them. Both were started from desktop shortcuts
    and closed after running a single command pasted in.

    Adding the VS2010 argument (Intel seems to suggest it is second!) may
    be a workaround. And maybe it should be VS2008. That is all fine until
    the next time Intel supplies a new version, which can be anywhere between two weeks to six months later. In the past the new versions had new version
    numbers and new directories but they now seem to keep a single name
    which looks like it was invented by the marketing department.

    In Unix on can use the other shells as subshells. Subshells does not appear
    in the TCMD manual but there may be some way to do it. That would be
    a more robust workaround.
     
  20. David Marcus

    Joined:
    Jun 4, 2008
    Messages:
    648
    Likes Received:
    1
    I think TCC matches the documented features and quite a few of cmd's undocumented features and bugs. That doesn't mean that every bat file runs identically in cmd and TCC, nor do I think "compatible" should imply that.

    But, this discussion is premature since you haven't figured out where the difference is. Why don't you isolate the problem first?

    Did you check the environment of each after starting them and before running the bat file?

    If you are at a TCC prompt and want to run cmd in the same window, just type "cmd". And, vice versa (giving the full path if the exe is not on your path).
     
  21. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    Desktop shortcuts can (and usually do) have significant differences in their
    environments.

    The easy way to test this is to start your CMD shell from your shortcut, and
    then run TCC.EXE inside that CMD shell. That way you'll be certain that CMD
    and TCC are using the same environment.

    Did you check your TCC environment to see if you had the VS2008COMNTOOLS
    variable defined? (If you don't, those batch files cannot work, in either
    CMD or TCC.)
     
  22. G.Sande

    Joined:
    Oct 20, 2011
    Messages:
    9
    Likes Received:
    0
    From the desktop shortcuts I:

    1. started the shell (i.e. either cmd.exe or TCMD)
    2. cd \Users\gordon
    3. set > xxx_set.lst for xxx of either cmd or tcmd
    4. closed the shell

    and then compared the two files.

    There were three differences of the sort that seems reasonable.

    ComSpec indicated the relevant program.
    cmd.exe had a PROMPT variable.
    TCMD has two variables of TCMD and TCMDVER.

    Both had VSSHELL2008INSTALLDIR and VSSHELL2010INSTALLDIR
    but no other obvious VS stuff.
     
  23. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,860
    Likes Received:
    83
    Then that's your problem. (A configuration problem, not a compatibility issue.)

    The missing environment variable on your system is VS90COMNTOOLS; without that your MSVS_VAR_SCRIPT variable won't be set, and you'll get the error when running the batch file.

    VS90COMNTOOLS isn't set by TCC, CMD, or the Intel batch files -- it's one of the variables that is set when you run the VCVARSALL.BAT file in the Visual Studio VC directory (which in turn calls the VCVARS32 or VCVARS64 batch file in the Visual Studio VC/BIN directory which actually set VS90COMNTOOLS).

    If you run VCVARSALL.BAT before running the Intel scripts (or for that matter doing *anything* from the command line with VC) everything should work as expected. (As it does here.)
     

Share This Page