running program from script and (not) returning to script

  • This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
#1
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?
 
#6
Code:
START /PGM "c:\path to\my\proggy.exe"
or
Code:
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
Code:
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

Administrator
Staff member
May 14, 2008
10,291
90
#7
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
Code:
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.
 
#8
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. :smile:
 

Charles Dye

Super Moderator
Staff member
May 20, 2008
3,482
44
Albuquerque, NM
prospero.unm.edu
#11
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.
 
#12
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

Administrator
Staff member
May 14, 2008
10,291
90
#13
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. :smile:
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.)