"start /affinity=<mask>", but cmd.exe doesn't use the "="

[MPB]

I was recently testing out a batch file that was written for cmd, and trying to add some TCC fanciness around it to make it work a little better.

In essence, the script will launch a program and it's assigning affinity and node to each one so they run on their own core.

The unusual thing started out because cmd.exe expects an argument like "/affinity 4 /node 1", but TCC expects an equal sign after affinity, so just for a TCC batch, I have to change it to "/affinity=4 /node 1"

It's also confusing because at first I thought that if affinity needed an equal sign, well, node must also, but nope. :) The documentation does indicate the correct syntax, it's just oddly inconsistent, and especially inconsistent with cmd.exe syntax, requiring that equals sign.

Maybe it's not a huge deal, and if I go further and migrate this to a purely tcc solution, there are plenty of other things that would make this a "tcc only" batch file (should probably rename it to a btm).

I just wondered if this was by design or oversight, and is it a big deal? Anyone else have problems with it? In my case it especially comes up if I'm in a tcc shell anyway and just wanted to test out the original, I'd get errors without that "=" in there, so even if I just wanted to run it as-is, I couldn't. And I can't fix it for tcc because the other admin on the system just uses plain cmd.

Thoughts? Is it worth bugging Rex to see if he can make that "=" optional in future builds so it's cmd.exe compatible?

 

[David Marcus]

if I'm in a tcc shell anyway and just wanted to test out the original, I'd get errors without that "=" in there, so even if I just wanted to run it as-is, I couldn't.

If you let cmd run your bat files and have tcc run only your btm files (which is what I do), will that solve your problem?

 

[MPB]

Well, that's one way to do it I suppose. I'm sure I'll forget at times when I'm in TCC doing things and just want to kick something off ad-hoc. That's when the CMD compatibility issues show up.

Anyway, it's a minor quibble, but I do like it when built-in commands between cmd and tcc have the same arguments, even when tcc adds extra ones.

A similar example is the built-in TCC command "tasklist", compared to the standard "tasklist.exe" that comes with Windows. Similar, but different. At least in that case I've just modified my batch files to specifically use "tasklist.exe" if that's the syntax I want to use. In the past I've also made exceptions for the built in "zip" command when I was using an external "zip.exe" for some batch processing of files.

I don't care about those so much, where the TCC command is the same as an external program. It's when it's the same as the built in cmd commands that the problems arise because there's no good way around it. Well, I guess I could add in some features to detect if it's running in tcc or not, with something like:
if %_tccver GTR 0 (<do it the tcc way>) else (<do it the cmd way>)

Or something like this to make it a little more granular:
set affinity=/affinity=40
if %_tccver GTR 0 set affinity=/affinity 40
start "My program" c:\myprogram.exe %affinity%

 

[Alpengreis]

Yes, could be worth to make a suggestion to enhance the compatibility with cmd.

 

[MPB]

I revisited this yesterday because I needed to fix up a script that's used by other team members, who don't use TCC, but I wanted it to work either way, with the only difference being that "affinity".

What I ended up doing was to set an "affoption=" variable to either "/affinity 4000" for CMD, and then if 01==1 set it to "/affinity=4000". When I launch the process, I just use %affoption% in the command to pick whichever one I set. :P Kludgy workaround, but it'll do for now.

I thought about putting in a check so that if it detects running with TCC it just exits out with a message, but I figured if I'm doing a detection anyway, why not add that bodge.

 

[ohenryx]

I have done similar things in the past. A bit of a pain, but the benefits of using TCC personally far outweigh the disadvantages -- at least for me.

 

[rconn]

This syntax is supported in v32.