|
Getting Started Quick Guide
FastTrack is a scripting language and is currently the only real high-level scripting language. Using all other scripting languages, you do a lot
of time consuming plumbing to accomplish things and the complexity of this alone prohibits you from doing a lot of things you
would like to do. Most other commonly used scripting languages are very close to programming languages and many of them are in fact the
counterparts of real programming languages, like VBScript. This means that you need programming skills
to script and often you find yourself using other people's snippets you find on the internet. It is very difficult to script
complex things even for a programmer and most places you won't find a programmer in the systems administrators department.
FastTrack is completely different. It is essentially
a gigantic toolbox and the paradigm is: one operation - one script line. If you need to synchronize files from one directory to
another you write one line in your script and FastTrack shows the user a friendly GUI while doing it. This of course
triggers hundreds of real codes lines in the engine, but you don't write the code to actually execute the operation,
you just specify what you want to accomplish.
This means, that if you have a relatively large WSH logon script today, you will be amazed how few script lines
you need to do the same with FastTrack. And on top of that your scripts will be far more readable and you wrote all
of it yourself instead of relying on other people's snippets or even consultants. If you have consultants this is the place
they don't want you to know about. Anyone with IT understanding
can write a FastTrack script that does complex things, so now you can use your energy one what you want
done instead of how and who you want to do it.
|
The editor
To write script, first of all you must
download and install the setup package.
Start the editor from the "FSH Script Editor" icon. It looks like this:
First time you start the editor, a demo script is opened. Try running it with F5 from the editor, which will execute a small demo script.
The script is not very useful, but the point is that it is all done in just a few simple script lines.
You can also press F6 and run a script in debug mode. Running in debug mode allows you to step through the script and see exactly
how the script is parsed at runtime.
The "Engine Browser" tree shows all commands, functions, collections and conditions.
When an item is marked in the tree, the "Context Helper" shows a full explanation of the selected item.
If you for instance need to execute a program, you locate the "Run" command in the tree and double-click it
to insert it into your script at the cursor position (or drag it into the script). A property builder is opened
to help you create the correct parameters.
The editor automatically highlights commands, functions, collections, conditions and loops (which are all explained further down this page).
When you move around your script, the editor senses what you do and if the cursor is on one of the highlighted items, it automatically
displays an explanation in the "Context Helper" panel. This happens completely on-the-fly as you type
letters or move around in the script. As you type, the case will also automatically be corrected. If you type the command "splash", it will
automatically be corrected to "Splash" (with a capital S).
The editor also has code completion. In the above screen dump, "co" was typed, and 5 commands are suggested.
You can disable the property builder, if you prefer to write the parameters directly in the script. If you do, a
template is copied into the script instead. You will most likely find that in the beginning, you use the property
builder, but as you get familiar with command, functions, etc, you will write the scripts directly with aid from the
code completion. A small tip on finding a command: When you write a new line, you can press space to open a full code completion window. When you select
a command, the space is removed.
To ensure script quality, a script validator is build into the editor. When you save or execute a script, a simulated run is performed to validate
if there are any syntactical errors in your script, like a missing parameter. If the script cannot pass a simulated run,
you will be notified of what line is the problem. This means that you cannot save or execute an invalid script, unless
you uncheck the "Validate Before Save" setting.
The editor is completely customizable. You can change the skin and move the panels around like in Visual Studio. This is the same editor where
a panel is dragged:
Writing scripts
FastTrack scripts generally consists of 5 types: Commands, functions, collections, conditions and loops.
Commands
A command is an operation that "does something", like performing a file operation, connecting a share, etc.
Everything else is basically there to support the commands. Click
here for a complete list of
current commands.
Functions
A function is notated with square brackets, like [UserFullName] and is replaced by what the function does.
In this case it would be replaced by the currently logged on users name. Click
here
for a complete list of current functions. Think of a function as a textual replacement before commands,
conditions and loops are executed. A command will see the replaced function value when it executes.
Functions can have parameters for instance [Var Server], which returns the
content of a variable named "Server". You can use functions inside functions like [UserFullName [Var user]].
The next example demonstrates use of functions.
Collections
A collection is essentially the same as a function, except that it returns a comma separated
list of values instead of just one value. This means that a collection is the same format as a list of parameters,
making collections very useful for loops or menus. The example in the loops section below demonstrates the use of it.
Click
here for a complete list of current collections.
If-statements with Conditions
A condition is used with an if-statement. If the condition is true, the inner code is executed,
otherwise not. You can always specify "not" after if for the opposite result. A condition consists of "IF.....Then" and has
to have en ending line "end if" and optionally have an "Else" in between.
If there is just one command that has to be executed if the condition is true, it can be specified after "Then". In that case there
can be no else or end if attached to it. An example of a conditional if-statement in one line can be seen in line 4 in the next example.
Click
here for a complete list of current conditions for if-statements.
If-statements with operators
If statements can also be used without conditions. You can use the operators <, > and =.
For "not equal to", you use the = operator and "not" after "If".
When they are used the engine simply compares the results on both sides of the operator, like in example
with IPAddressPart below.
This example is script in the Startup folder of a computer which determines if it is at home or at work, which
uses all of the above "If" constructs:
 |
|
SmallSplash "Connecting,
please wait..."
DisconnectAllShares
If [IPAddressPart
3]=192.168.1
Then
If Alive MyHomeServer Then
ConnectShare O:,\\MyHomeServer\D$
SetPrinterDefault \\MyHomeServer\HomePrinter
Else
If Not ProcessRunning outlook
Then LaunchMin [ProgramFilesDir]\Microsoft
Office\Office12\OUTLOOK.EXE
SetPrinterDefault \\ACMESERVER\PRT012
End If
|
 |
If-statements with multiple conditions
Regular AND and OR operators are possible as shown below where a documents backup is
performed, if the computer is a portable computer and it is running on A/C.
 |
|
If Portable And
Not RunningOnBatteries Then SyncDir [UserDocumentsDir],[UserHomeDir]\DocumentsBackup
|
 |
Loops
Loops are just means to iterate through collections, which has to be ended with "End Loop".
The first parameter is always the name of variable you choose which contains the actual value inside the loop.
This example synchronizes a data directory to all citrix servers in a farm:
 |
|
Loop Server,[CitrixServers]
SyncDir C:\Data,\\[Var Server]\d$\Data
End Loop
|
 |
Parameters
Parameters are always separated by commas and can optionally be written inside quotes. This means
that if a parameter itself contains a comma, the parameter must be quoted. Take a look at this example:
 |
|
If [FreeDiskSpace]<5 Then
ShowMessage "Your harddrive space is too low, contact
HelpDesk",Error
|
 |
If the first parameter was not quoted, the engine would have considered the first parameter as two parameters,
yielding a "too many parameters" error from ShowMessage. You don't have to use quotes in general, but remember that
you must quote anything that may contain commas. Also remember that a function that may return something with
comma must also be quoted.
Variables
A variable is defined with the command "SetVar" and retrieved again with the function "Var".
This example would present a menu with the names of all local groups and put the selected
one into the variable "Group". The second line would display the content of the variable
"Group" in a messagebox:
 |
|
SetVar Group,[Menu
Select a group,[LocalGroups]]<br />
ShowMessage [Var Group],You selected
|
 |
Escape
Functions and collections are residing inside square brackets, [ and ]. You will most likely never experience it, but
if you in fact need the bracket characters themselves for for instance writing a registry value that
contains them, you must use the char function. The [Char 91] function will produce a start bracket char
and [Char 93] will produce an end bracket char.
Comments
Comments can be used anywhere, and is noted as ''. Anything beyond it on a line is considered a comment.
Block comments must start with /* and end with */.
Labels
Any line that starts with a colon is considered a variable. In most other scripting and programming languages, labels
cannot contain spaces for parsing reasons. This is not the case with FastTrack scripts, labels can in fact contain spaces.
The reason for this is that in almost any case you would need goto, spaces will be involved.
Take a look at this example which is a menu to easily synchronize data to a selectable server:
 |
|
SetVar Selected,[Menu
Select operation,Replicate to Server 1,Replicate to Server
2,Replicate to Server 3]
If Not [Var
Selected]= Then
Goto [Var Selected]
Exit
:Replicate
to Server 1
SyncDir C:\Data,\\Acme\Server1\Data
Exit
:Replicate
to Server 2
SyncDir C:\Data,\\Acme\Server2\Data
Exit
:Replicate
to Server 3
SyncDir C:\Data,\\Acme\Server3\Data
Exit
|
 |
Embedding other scripting languages
If you have a script written in another scripting language that you want to include within
your FastTrack Script, you can simply issue a Run command. The Run command uses shell execution,
meaning that you do not need to specify the executable to handle a specific file type,
if there is already an association to the specific scripting type.
If you need to hand over a status from the embedded script, or an executable, you can
facilitate exit codes. In VBScript, you can optionally supply an exit code to VBScript.Quit
like this:
 |
|
WScript.Quit(200)
|
 |
Inside your FastTrack Script your then read this status by using the LastExitCode function:
 |
|
Run AcmeScript.vbs
If [LastExitCode]=200 Then
''...Do something...
End If
|
 |
Running scripts outside the editor
To run scripts outside the editor on your own machine, you simply double-click the saved fsh file and it gets executed. This will just pass the
script file as the only parameter to the fsh.exe file, which is the only file you need to execute a script.
But most likely the actual use of the script is on other machines than the one you created the scripts on.
To execute a script on another machine you need nothing but the fsh.exe file from the installation directory
on the target machine. Just pass the script as the only parameter like this:
 |
|
FSH.Exe MyScript.fsh
|
 |
To see the command line options, just start the "Language reference" icon in the start menu and look at the last tab.
If you have a license, you must put a copy of you fsh.lic file in the same directory as the fsh.exe
to avoid the trial window. You may also optionally copy an error handler and/or a post installation script with the exe file,
this is described later in the article. Note that FastTrack cannot run directly off a network unless you grant the intranet zone full rights on the machine.
For distributing to all clients in a network, we highly recommend you use the free FastTrack Logon. It will automatically distribute
the engine and logon scripts to all clients seamlessly. See the logonscript menu for details.
Error handling
Error handling is essential in any script or program and you can decide how you want it handled.
If there is a file called "ErrorHandler.fsh" in the same directory as the engine (fsh.exe), it gets executed when a fault happens.
You should especially use it with FastTrack Logon. Creating this single line in ErrorHandler.fsh with FastTrack Logon:
 |
|
AppendFile \\AcmeServer\ITShare\NetworkErrors.log,"[Date],[Time],[Username],[LastError]"
|
 |
...will append
all execution errors on the entire network to the file.
Consider the amazing overview you would get as a systems administrator, all errors on all machines logged in a single file!
The engine has two parameters related to the way faults are handled. In general there is a distinction between runtime
errors and script errors. Script errors (malformed script like a wrongly spelled command) by default stop the script execution
entirely and shows the error to the user, but runs the error handler script. Runtime errors (like users full name cannot be
retrieved because a domain controller cannot be reached) also by default stops execution and runs the error handler. But you
can decide a different behavior with command-line parameters. If you specify /ie, runtime errors will not stop the execution
and every time a runtime error occurs the error handler script is executed. If you use this switch, all functions will return
a blank string if it fails and conditions are not entered if the condition fails. You can also ignore script faults with /if,
but this is not recommended because you might never find out that your script is malformed. FastTrack Logon executes
logonscripts with /ie to ensure full execution. If you used the line above, you will know what fails instead of showing it
to user. The execeution of the ErrorHandler.fsh is a bit blindfolded. It does not include itself again if there is a
fault it in, since this would produce an infinite loop, so be sure you script actually works.
If it is complex, you should test it by executing it directly.
Where to go from here...
Hopefully, you now have an understanding of how FastTrack works. What can you do with it then?
You can of course do anything you could do with other scripting languages, but you will also find,
that you can do much much more. Your logonscript can with very few script lines handle location based connection of shares and printers,
apply user settings, do cleanups and checks and the single most important new thing is that you can get a centralized log of all
execution errors just by filling in one line in ErrorHandler.fsh. This gives you
an extreme insight to what goes on "out there" that you never had before and you just wrote one script line to do it. Look in the
Logon Script menu for more details on creating login scripts.
You can also script all your installations with simple FastTrack scripts or just wrap
your existing scripts. You couls then use your logonscript to solve the classic usersettings problem, this is described in more detail
in the Installation menu.
You can also do administrative tasks like replicating
data between servers or backing up files with synchronization. You can write small scripts to handle
launching of user applications based on script logic and much much more, the possibilities are endless once you understand
the power of the script engine. And you can do all the same things for Terminal Servers and Citrix solutions and a few tricks more.
You can log people off, if the user uses a certain citrix application on client locations you don't want them to run it from, because you
can get the clients IP address and workstation name in a citrix logon script.