This is the documentation of an pre-release opsi version. The documentation for the current version 4.3 can be found here.

The 'opsi-script' Script

On principle: 'opsi-script' is an interpreter for a specific, easy to use scripting language which is tailored for the requirements of software installations. A script should be an integrated description, and a means of control, for the installation of one piece of software.

The following section sketches the structure of a 'opsi-script' script. The purpose is to identify the book marks of a script: in which way we to have to look into it, to understand its processing.

All elements shall be described more in detail in the further section. The purpose then will be to show how scripts can be modified or developed.

An Example

'opsi-script' scripts are roughly derived from .INI files. They are composed of sections, which are marked by a title (the section name) which is written in brackets [].

Schematically a 'opsi-script' script looks like this one (here with a check which operating system is installed):

[Actions]
Message "Installation of Mozilla"
SetLogLevel=6

;which Windows-Version?
DefVar $MSVersion$

Set $MSVersion$ = GetMsVersionInfo
if CompareDotSeparatedNumbers($MSVersion$,">=","6")
  sub_install_winnt6
else
  stop "not a supported OS-Version"
endif

[sub_install_winnt6]
Files_copy_winnt6
WinBatch_Setup

[Files_copy_winnt6]
copy "%scriptpath%\files_win10\*.*" "c:\temp\installation"

[WinBatch_Setup]
c:\temp\installation\setup.exe

How can we read the sections of this script?

Primary and Secondary Subprograms of a 'opsi-script' script

The script as a whole serves as a program, an instruction for an installation process. Therefore each of its sections can be seen as a a subprogram (or "procedure" or "method"). The script is a collection of subprograms.

The human reader as well as an interpreting software has to know at which element in this collection reading must start.

Execution of a 'opsi-script' script begins with working on the [Actions] section. All other sections are called as subroutines. This process is only recursive for Sub sections: Sub sections have the same syntax as Actions sections and may contain calls for further subroutines.

If a script is run as 'userLoginScript' and it contains a section [ProfileActions], so the script interpretation will be started at the ProfleActions section.

This gives reason to make the distinction between primary and secondary subprograms:

The primary or general control sections comprise

  • the Actions section

  • Sub sections (0 to n subroutines called by the Actions section which are syntactical and logical extensions of the calling section).

  • the ProfileActions section, which will be interpreted in different ways according to the script mode (Machine/Login).

The procedural logic of the script is determined by the sequence of calls in these sections.

The secondary or specific sections can be called from any primary section but have a different syntax. The syntax is derived from the functional requirements and library conditions and conventions for the specific purposes. Therefore no further section can be called from a secondary section.

At this moment there are the following types of secondary sections:

  • Files sections,

  • WinBatch sections,

  • ShellScript sections,

  • Registry sections

  • Patches sections,

  • PatchHosts sections,

  • PatchTextFile sections,

  • XMLPatch sections (discouraged),

  • XML2-Sektionen,

  • LinkFolder sections,

  • opsiServiceCall sections,

  • ExecPython sections,

  • ExecWith sections,

  • LDAPsearch sections.

Meaning and syntax of the different section types are treated in Syntax and Meaning of Primary Sections of a opsi-script Script and Secondary Sections.

String Expressions in a opsi-script Script

Textual values (string values) in the primary sections can be given in different ways:

  • A value can be directly cited, mostly by writing in into (double) citation marks. Examples:
    '"Installation of Mozilla"'
    '"n:\home\username"'

  • A value can be given by a String variable or a String constant, that "contains" the value:
    The variable '$MsVersion$' may stand for "6.1" – if it has been assigned beforehand with this value.

  • A function retrieves or calculates a value by some internal procedure. E. g. EnvVar ("Username")
    fetches a value from the system environment, in this case the value of the environment variable 'Username'. Functions may have any number of parameters, including zero:
    GetMsVersionInfo
    On a win7 system, this function call yields the value "6.1" (not as with a variable this values has to be produced at every call again).

  • A value can be constructed by an additive expression, where string values and partial expressions are concatenated - theoretically "plus" can be seen as a function of two parameters:
    '$Home$ + "\mail"'

(More on this in String Expressions, String Values, and String Functions)

There is no analogous way of using string expressions in the secondary sections. They follow there domain specific syntax. e.g. for copying commands similar to the windows command line copy command. Up to this moment it is no escape syntax implemented for transporting primary section logic into secondary sections.

The only way to transport string values into secondary sections is the use of the names of variables and constants as value container in these sections. Lets have a closer look at the variables and constants of a 'opsi-script' script: