running program from script and (not) returning to script

[MickeyF]

I'm running an program which, if I run it directly from the command line, starts up the program and my TCC (v. 16.03, Windows 7-64) window returns me to my command prompt, with the program running happily in the foreground. If I run that same program from within a batch (.BTM) file, the program starts, but my batch file is paused, waiting until my program terminates. How do I get it to start that program but just return immediately to my batch script?

 

[rconn]

Use START. Running an app from a batch file will otherwise default to waiting for the program to terminate (so that you can get the return code).

 

[MickeyF]

Use START. Running an app from a batch file will otherwise default to waiting for the program to terminate (so that you can get the return code).

I tried that. Yes, my original TCC window returned immediately, but it started up a new TCC window.

 

[Charles Dye]

START /PGM "c:\path to\my\proggy.exe"

or

START "" "c:\path to\my\proggy.exe"

 

[Charles Dye]

Without the /PGM, the first quoted string is interpreted as the title for a new console window -- probably not what you want. Yes, this syntax is bizarre! It's for CMD.EXE compatibility, of course.

 

[MickeyF]

START /PGM "c:\path to\my\proggy.exe"

or

START "" "c:\path to\my\proggy.exe"

OK, I've figured out that there's a twist I didn't realize was significant, but have now determined that it is. If I use the simple

START "" prog.exe arg1 arg2

, it works properly. However, the twist is that instead of prog.exe, I have an alias that is as basic as it comes - the alias simply defines the program to run.

I've fixed it by merely using a system environment variable to define the program to run instead of an alias. However, I am curious why using an alias here causes it to create a new TCC window.

 

[rconn]

OK, I've figured out that there's a twist I didn't realize was significant, but have now determined that it is. If I use the simple

START "" prog.exe arg1 arg2

, it works properly. However, the twist is that instead of prog.exe, I have an alias that is as basic as it comes - the alias simply defines the program to run.

I've fixed it by merely using a system environment variable to define the program to run instead of an alias. However, I am curious why using an alias here causes it to create a new TCC window.

If the command that you're passing to START is an internal command, alias, or batch file, START will start another TCC.EXE session to execute it.

 

[MickeyF]

If the command that you're passing to START is an internal command, alias, or batch file, START will start another TCC.EXE session to execute it.

Oh, so START is the pure CMD implementation. There's no TCC (TCMD) version of it that could shield it from something like that. Might I suggest (at a very low priority) that there be a TCC version of START that can treat the internal commands and aliases as not having to start another TCC session? Basically, I thought that having an alias there would be exactly the same as having the actual program there, just like the environment variable case is handled. But I'm OK even if you choose not to implement this. As long as I understand how it works, which I now do.

 

[Charles Dye]

There is actually a function to expand an alias:

START /PGM %@ALIAS[myalias]

 

[MickeyF]

There is actually a function to expand an alias:

START /PGM %@ALIAS[myalias]

Of course there is!

 

[Charles Dye]

Thinking further about your issue: Rather than updating all your batch files to use START, it might be smarter to change your alias to START /PGM "PROGGY.EXE". The new alias ought to work the same at the command line -- but do what you expect in batch files.

 

[MickeyF]

I'll keep that in mind for future applications. I only had one batch file for this particular issue, and simply changing from an alias (that was otherwise unused anyway) to an environment variable was simple and straightforward. But thanks for the great suggestion!

 

[rconn]

Oh, so START is the pure CMD implementation. There's no TCC (TCMD) version of it that could shield it from something like that. Might I suggest (at a very low priority) that there be a TCC version of START that can treat the internal commands and aliases as not having to start another TCC session? Basically, I thought that having an alias there would be exactly the same as having the actual program there, just like the environment variable case is handled. But I'm OK even if you choose not to implement this. As long as I understand how it works, which I now do.

The START in TCC is vastly expanded versus the START in CMD. However, there's no way that you can run an alias, batch file, or internal command by itself, so TCC has to invoke another copy of TCC to execute it. (If you didn't want another TCC session, there wouldn't have been any point in using START in the first place.)