Executing external programs

This page sums up the basics of starting an external application/program from a script. To execute an external application, there are basically two versions: Run and Launch. The difference between them is that Run waits for the application to finish and Launch will just spawn the application and continue script execution. Run and Launch come in slightly different variations:

Parameter splitting

If you look at the Context Helper for most of the above commands, you will see that you are expected to split the application and the optional parameters as two separate FastTrack parameters. The engine can execute in Windows compatible style, but best practice is to make the correct splitting, because then you do not need to do all the normal Windows quoting for paths containing spaces.

If we wanted to start the media player with the "Tada" jingle from a batch file or from the explorer, we basically need to execute:
This will result in an error and we understand that Windows cannot determine what is what, because the application to execute has a space in the path. So we need to go:
Now it would be perfectly logical, if we would do this in our FastTrack script:
If you are using version 8.2 or newer, this does in fact work. But it is not best practice. This is what is called implicit splitting, meaning that you are not saying what is actually the executable and what are parameters. Best practice is to use explicit splitting, where you actively tell the engine what is what:
Note that quotes are no longer necessary, because we have explicitly said what is the application and what are parameters. You can still use quotes, but the only scenario, where you need to quote something is when there is a comma in the application path or parameters.

In this case we are using the paths for the 32-bit Program Files directory and the Windows directory. Best practice with FastTrack is to never hardcode these paths, as explained here, make sure scripts work across different versions of Windows and across 32-bit and 64-bit. So the best practice version would be:

The console

Generally speaking, you can run a console application just like any other application, as for example calling sqlcmd.exe for SQL Server. If the started application is a console application, a command prompt will automatically be started. So if we went:
...a console Window will show up briefly and close again, as shown below, just as if we started sqlcmd.exe from a batch file or from the Windows "Run" function.


As shown here you should use the internal SQL commands for this type of operation, but we will use this as an example here.

If we wanted to set this up as a recurring scheduled task, we would want to get the status of this operation and send an email to someone. This would require us to get the output of this operation. We can do this by piping the output to a file and then read this file. This solution is unnecessarily complicated and unreliable. To make capture of output easier, there is a build-in console in FastTrack to replace the standard command window. Functionality to use the console can be found under "Execution Console" in the Engine Browser tree in the script editor. If we re-wrote this a bit, then we could go:
The last line should be omitted, but is used here to be able to see the output before the scripts exists. This puts a "Close" button on the console window and waits for the user to click it, similar to using the Pause command in a batch file. Instead of showing the standard command prompt, we now get the build-in console instead:


This replacement console is used, when using the command RunCMD without credentials. Using multiple RunCMD commands in a script will continue to use the same console window. Using RunCMDHidden will not show the console, but the output will still be captured. The launch versions and using RunCMD with credentials or RunCMDElevated will either be executing as a different user or use a different process token. It is then not possible to access to the console output and therefore the Windows console window will be used. If you need to change user or elevate and show the replacement console, you must use the ChangeUser or ElevateUser command first and then use RunCMD without credentials.

There can be scenarios where a console application must be shown to end users and this way it presents itself nicer. If you have existing batch files you would like to use the FastTrack Console with, you can just pass the existing batch file to RunCMD. But the main purpose of the build-in console is to get access to the output. So if we now go:
The total output of the last command, in this case SQLCMD.exe, can be retrieved with the LastCMDOutput function. In this case we get:


If we wanted to email the status, we would only want the last output line. We can iterate all the output lines using the ConsoleLines collection:
We are iterating through all the lines currently displayed in the console to get the last line. For demonstration purposes, we are just displaying this last line, but we could use the variable LastLine as part of the string to email using the SendMail command. The above script would show this: