Alias - launch external program - batch file

[nikbackm]

Scenario:

1. You have an alias that launches an external (Win32 GUI) program.
2. You want to use the alias in a batch file.
3. You don't want the batch file to wait for the alias (the external program) to complete.

How to best accomplish this?

The obvious solution is to use START, but this also causes a new TCC (session and console window) to be started.
You can specify /C so this is stopped as well when the external program is, but it's still not quite satisfactory.
Optionally /MIN and /INV can be used to make it look less ugly, but /MIN still starts a visible TCC window (taskbar)
and /INV may cause problems in cases where the alias is not alias at all, but in fact the name (in %path%) of the
external program. Both of them also causes an unnessary TCC instance to be running (hidden or not) as long as the external program is.

So I'll add:

4. The started command/alias may sometimes NOT be an alias, but starting it without waiting should still work the same way.

Anything other than START which could be useful?

Temporarily disabling waiting on external programs in batch files perhaps? That would make it work just like running the alias from the command line which I guess is a short summary of what I want.

Failing that, any "best practices" to share for such scenarios? I guess you could always test the supposed alias with IF ISALIAS and such to use different START parameters, but something simpler would be preferrable.

 

[K_Meinhard]

nikbackm wrote:

> 4. The started command/alias may sometimes NOT be an alias, but
> starting it without waiting should still work the same way.

What happens when you enter the command or alias "naked", without START?

herzliche Grüße,

Klaus Meinhard

 

[K_Meinhard]

nikbackm wrote:

> 4. The started command/alias may sometimes NOT be an alias, but
> starting it without waiting should still work the same way.

What happens when you enter the command or alias "naked", without START?

herzliche Grüße,

Klaus Meinhard

 

[Steve Fabian]

---- Original Message ----
From: nikbackm
| Scenario:
|
| 1. You have an alias that launches an external (Win32 GUI) program.
| 2. You want to use the alias in a batch file.
| 3. You don't want the batch file to wait for the alias (the external
| program) to complete.
|
| How to best accomplish this?
|
| The obvious solution is to use START, but this also causes a new TCC
| (session and console window) to be started.
| You can specify /C so this is stopped as well when the external
| program is, but it's still not quite satisfactory.
| Optionally /MIN and /INV can be used to make it look less ugly, but
| /MIN still starts a visible TCC window (taskbar)
| and /INV may cause problems in cases where the alias is not alias at
| all, but in fact the name (in %path%) of the
| external program. Both of them also causes an unnessary TCC instance
| to be running (hidden or not) as long as the external program is.
|
| So I'll add:
|
| 4. The started command/alias may sometimes NOT be an alias, but
| starting it without waiting should still work the same way.
|
| Anything other than START which could be useful?
|
| Temporarily disabling waiting on external programs in batch files
| perhaps? That would make it work just like running the alias from the
| command line which I guess is a short summary of what I want.
|
| Failing that, any "best practices" to share for such scenarios? I
| guess you could always test the supposed alias with IF ISALIAS and
| such to use different START parameters, but something simpler would
| be preferrable.
---- End Original Message ----

I believe you misinterpret the statement below in HELP topic start.htm:
"START is used to begin a new session, and optionally run a program in that session."
I do not read it to mean a "new TCC session", but to mean a "new Windows session". I have many aliases and batch files which use the START command, without using its /WAIT option, to start GUI programs. They complete without waiting for the termination of the GUI program, whether they are started from the command line of an existing TCC session or from new, temporary sessions started e.g. from the QuickLaunch bar. Many of them send keystrokes to the GUI program, using the ACTIVATE and KEYSTACK commands, for example, to log in to interactive browser sessions of specific URLs. These work whether or not the browser was already running.
--
HTH, Steve

 

[nikbackm]

nikbackm wrote:
What happens when you enter the command or alias "naked", without START?

At the command prompt:
The external program starts and the prompt directly returns for entering more commands.

In a batch file:
The external program starts and the batch file waits until it exits before running the next command/line.

 

[rconn]

If you try to START an alias or batch file, TCC has to invoke another copy of TCC in order to execute the alias / batch file in the new session.

Just change your alias (or create a new one) that does the START in the alias itself.

 

[nikbackm]

Thanks for all answers!

Looks like using START in the alias definition would be the best choice in my case. Not that many aliased programs that I want to call from batch files this way.

It's not a perfect solution of course. This way you need another alias when you don't want the START semantics, and you cannot use another alias in the definition of the alias using START. (Well, you can, but then you get the extra unwanted TCC session/window "problem" again. Luckily directory aliases can be used without that having effect though)

I guess the there is no extra side-effects to using START in alias:es called from the command prompt when "Wait for external apps" is disabled?

Also, would having batch files behave as the command line be default does in regards to running external apps be hard to do, or is it just that no one has found that useful and requested it? Overall that would seem the cleaner solution in some cases, even if it might be of rare use. Not really that important for me personally, just curious.

 

[vefatica]

On Wed, 22 Dec 2010 10:19:56 -0500, rconn <> wrote:

|If you try to START an alias or batch file, TCC has to invoke another copy of TCC in order to execute the alias / batch file in the new session.
|
|Just change your alias (or create a new one) that does the START in the alias itself.

And give that START command the option "/B" (no new console).

 

[samintz]

Niklas,

I'm not real clear on why you *need* to use an alias. If you're creating
a batch file, why not just specify the full command instead of an alias?

As an alternative, you could pre-expand the alias prior to invoking START.

Something like:

set mycmd=%@ALIAS[myalias]
start %mycmd

-Scott


nikbackm <> wrote on 12/22/2010 11:57:57 AM:

> Thanks for all answers!
>
> Looks like using START in the alias definition would be the best
> choice in my case. Not that many aliased programs that I want to
> call from batch files this way.
>
> It's not a perfect solution of course. This way you need another
> alias when you don't want the START semantics, and you cannot use
> another alias in the definition of the alias using START. (Well, you
> can, but then you get the extra unwanted TCC session/window
> "problem" again. Luckily directory aliases can be used without that
> having effect though)
>
> I guess the there is no extra side-effects to using START in alias:
> es called from the command prompt when "Wait for external apps" is

disabled?

>
> But would having batch files behave as the command line be default
> does in regards to running external apps be hard to do, or is it
> just that no one has found that useful and requested it? Overall
> that would seem the cleaner solution in some cases, even if it might
> be of rare use. Not really that important for me personally, just

curious.

 

[rconn]

Also, would having batch files behave as the command line be default does in regards to running external apps be hard to do, or is it just that no one has found that useful and requested it? Overall that would seem the cleaner solution in some cases, even if it might be of rare use. Not really that important for me personally, just curious.

It would mean abandoning compatibility with CMD, and breaking a few zillion existing batch files.

 

[rconn]

And give that START command the option "/B" (no new console).

The OP was launching a GUI app, so /B wouldn't have any effect.

 

[vefatica]

On Wed, 22 Dec 2010 14:47:33 -0500, rconn <> wrote:

|---Quote (Originally by vefatica)---
|And give that START command the option "/B" (no new console).
|---End Quote---
|
|The OP was launching a GUI app, so /B wouldn't have any effect.

In his first post he was complaining about the new console, trying to minimize
and hide it. Don't you get a new TCC if you START an alias? But it shouldn't
be a problem if he aliases a START as you suggested.

 

[samintz]

The correct answer to your question is to use the START command. Depending
on whether the app you are starting is a GUI app or a console app will
affect whether a new TCC session is started or not. If the app you are
launching is a GUI app, then you should not be getting a new TCC session.

Whether you use an alias or not should not make any difference, other than
your aliases may or may not be available in child processes depending on
your local/global INI settings.

Can you share with the class what the command line is you are using to
launch your app(s)?

-Scott

nikbackm <> wrote on 12/22/2010 05:03:11 AM:

> Scenario:
>
> 1. You have an alias that launches an external (Win32 GUI) program.
> 2. You want to use the alias in a batch file.
> 3. You don't want the batch file to wait for the alias (the external
> program) to complete.
>
> How to best accomplish this?
>
> The obvious solution is to use START, but this also causes a new TCC
> (session and console window) to be started.
> You can specify /C so this is stopped as well when the external
> program is, but it's still not quite satisfactory.
> Optionally /MIN and /INV can be used to make it look less ugly, but
> /MIN still starts a visible TCC window (taskbar)
> and /INV may cause problems in cases where the alias is not alias at
> all, but in fact the name (in %path%) of the
> external program. Both of them also causes an unnessary TCC instance
> to be running (hidden or not) as long as the external program is.
>
> So I'll add:
>
> 4. The started command/alias may sometimes NOT be an alias, but
> starting it without waiting should still work the same way.
>
> Anything other than START which could be useful?
>
> Temporarily disabling waiting on external programs in batch files
> perhaps? That would make it work just like running the alias from
> the command line which I guess is a short summary of what I want.
>
> Failing that, any "best practices" to share for such scenarios? I
> guess you could always test the supposed alias with IF ISALIAS and
> such to use different START parameters, but something simpler would
> be preferrable.
>
>
>
>

 

[samintz]

The correct answer to your question is to use the START command. Depending
on whether the app you are starting is a GUI app or a console app will
affect whether a new TCC session is started or not. If the app you are
launching is a GUI app, then you should not be getting a new TCC session.

Whether you use an alias or not should not make any difference, other than
your aliases may or may not be available in child processes depending on
your local/global INI settings.

Can you share with the class what the command line is you are using to
launch your app(s)?

-Scott

nikbackm <> wrote on 12/22/2010 05:03:11 AM:

> Scenario:
>
> 1. You have an alias that launches an external (Win32 GUI) program.
> 2. You want to use the alias in a batch file.
> 3. You don't want the batch file to wait for the alias (the external
> program) to complete.
>
> How to best accomplish this?
>
> The obvious solution is to use START, but this also causes a new TCC
> (session and console window) to be started.
> You can specify /C so this is stopped as well when the external
> program is, but it's still not quite satisfactory.
> Optionally /MIN and /INV can be used to make it look less ugly, but
> /MIN still starts a visible TCC window (taskbar)
> and /INV may cause problems in cases where the alias is not alias at
> all, but in fact the name (in %path%) of the
> external program. Both of them also causes an unnessary TCC instance
> to be running (hidden or not) as long as the external program is.
>
> So I'll add:
>
> 4. The started command/alias may sometimes NOT be an alias, but
> starting it without waiting should still work the same way.
>
> Anything other than START which could be useful?
>
> Temporarily disabling waiting on external programs in batch files
> perhaps? That would make it work just like running the alias from
> the command line which I guess is a short summary of what I want.
>
> Failing that, any "best practices" to share for such scenarios? I
> guess you could always test the supposed alias with IF ISALIAS and
> such to use different START parameters, but something simpler would
> be preferrable.
>
>
>
>

 

[vefatica]

Why do I see Scott's recent post in this thread twice, with timestamps differing by an hour?

 

[nikbackm]

Niklas,

I'm not real clear on why you *need* to use an alias. If you're creating
a batch file, why not just specify the full command instead of an alias?

As an alternative, you could pre-expand the alias prior to invoking START.

Something like:

set mycmd=%@ALIAS[myalias]
start %mycmd

I *can* specify the full path but I generally prefer not to, at least not with utility commands that I use on several computers with programs potentially stored in different places. So having an ALIAS.LST with a list of common aliases makes this easier for me.

Writing out the full path is also more work with frequently used commands and does not look as nice. :)

The %@alias[] trick is quite neat though, don't think I will use it for this, but it might come in handy some time. Thanks for that.

Other options I've considered is adding the program directory to %PATH%, but I generally prefer to minimize that. Yet another one is adding it to the "App Paths" registry key, but I don't care to keep anything like that in sync on multiple computers either when alias.lst works better.

It would mean abandoning compatibility with CMD, and breaking a few zillion existing batch files.

True. Making the user opt-in (via SETDOS or similar) would surely be advisable with such a change. :)

The correct answer to your question is to use the START command. Depending on whether the app you are starting is a GUI app or a console app will affect whether a new TCC session is started or not. If the app you are launching is a GUI app, then you should not be getting a new TCC session.

Don't think you will get a new TCC session for all console apps, only when you start an alias, batch file or internal TCC command. STARTI:ing something like DIRUSE.EXE should not start a new TCC session(process) as well.

Can you share with the class what the command line is you are using to
launch your app(s)?

Well, one alias I use is "bc2" to start the "Beyond Compare 2" program.

alias.lst
=========
bc2="C:\Program Files\Beyond Compare 2\bc2.exe"


It's launched as simply "bc2 <file1> <file2>" from both the command line or in batch files. Except in batch files I have to use something like:

start /C /INV /PGM bc2 file1 file2

to avoid the extra TCC instance since bc2 is an alias.


But that can (now) be avoided by this alias definition:

alias.lst
=========
bc2="C:\Program Files\Beyond Compare 2\bc2.exe"
startbc2=start /PGM "C:\Program Files\Beyond Compare 2\bc2.exe" %$

and following use in batch files:

startbc2 file1 file2

Could also just use START in the bc2 alias and not add an exrta startbc2 alias I guess as having the unnecessary START should not matter when bc2 is run from the command line, but it might be better for clarity to have start in the name.

 

[samintz]

Considering I made that reply early yesterday morning and it didn't show
up until *after* the second post I made, I'm interested in knowing that
too.

-Scott

vefatica <> wrote on 12/22/2010 11:33:45 PM:

> Why do I see Scott's recent post in this thread twice, with
> timestamps differing by an hour?
>
>
>
>