TCMD does not get same result as cmd.exe

[G.Sande]

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?

 

[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

 

[Charles G]

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: [email protected]
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?

 

[samintz]

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:

> 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?
>
>

 

[Charles G]

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: [email protected]
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: [email protected]
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?

 

[G.Sande]

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.

 

[Charles Dye]

TCStart.bat calls ifortvars.bat which calls compilervars_arch.bat. The error message gives unknown command amd64 at line 215.

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?

 

[samintz]

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

 

[G.Sande]

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.

 

[David Marcus]

Change "echo off" to "echo on" in the files and try running under both cmd and TCC to see what the difference is.

 

[rconn]

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").

 

[G.Sande]

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.

 

[David Marcus]

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.

 

[G.Sande]

>> 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.

 

[David Marcus]

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.

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.

 

[G.Sande]

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.

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.

 

[David Marcus]

I have been dealing with the responses that have arrived by email. What is it that an I supposed to be doing?

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.

The cmd.exe and TCMD are executed one after the other with no attempt to change the environment.

How are you "executing" (starting) them?

If the two programs think the environment has changed then their dealing with the environment is not done in a compatible fashion.

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.

 

[G.Sande]

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.

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.

 

[G.Sande]

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").

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.

 

[David Marcus]

Perhaps there is some other definition of compatible. Matching undocumented features is sometimes a moving target.

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?

Both were started from desktop shortcuts

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

Subshells does not appear in the TCMD manual but there may be some way to do it.

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).

 

[rconn]

> 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.

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.)

 

[G.Sande]

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.)

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.

 

[rconn]

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

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.)