4. Variables
Prev   Next

4. Variables

4.1. Basic Syntax

Installer variables are an important concept in InstallBuilder. They allow you to store user input, temporary values, establish flags and use that information at different points during the build and installation processes. There are a number of built-in variables and you are also able to create them directly. The basic way of creating or changing the value of a variable in InstallBuilder is using the <setInstallerVariable> action:

 <setInstallerVariable name="foo" value="bar"/>

The action above will store the value bar in the variable foo. Once you have defined the variable, its value can be accessed in any other part of the project as ${foo}. If you require a variable that you are creating at install time to be also available in the uninstallation steps, you have to set the optional persist attribute to 1:

 <setInstallerVariable name="foo" value="bar" persist="1"/>

At uninstallation time, this variables will contain the value of the last assignment using the persist property.

Variable names must not contain characters other than digits, letters, dashes and underscores. There is only one exception to this rule: it is possible to use a variable as part of the name of another variable (as long as it is a valid one).

For example, if you have a variable foo with a value of bar, then:

 <setInstallerVariable name="${foo}" value="Hello"/>

will be equivalent to:

 <setInstallerVariable name="bar" value="Hello"/>

In addition to regular variables, parameters can also be accessed as variables. One good example is the well-known installdir variable which is in reality a <directoryParameter>:

<runProgram program="${installdir}/myApplication.run" programArguments="--install"/>

Some additional information to take into account when working with variables is:

  • Curly brackets are mandatory: Although the syntax is similar to the notation used in Unix bash-like shells to access variables, it is not the same. If $foo is used instead of ${foo}, it will not be resolved but treated as a literal string.
  • Accessing an undefined variable will not throw an error. Instead, if the variable name was bar, the value will be set to ***unknown variable bar***
  • Variables are not case sensitive. This means that you can use any of the following variants, ${variablename}, ${VariableName} or ${VARIABLENAME} and obtain the same value in all cases.

4.2. Modifier Suffixes

When accessing a variable, some operations can be specified through the usage of special suffixes:

  • ${installdir.dos}: If the variable contains a path, this modifier returns the DOS-style name for it. This will only take effect if the file exists and the platform is Windows. This is particularly useful when the value of the variable may contain spaces and you need to pass it as an argument to a program. Using the .dos suffix will remove the need of quoting the path as spaces will be removed. Take into account that using .dos over a path with forward slashes won’t convert them to backslashes.
  • ${installdir.unix}: If the variable contains a path, it will be converted to a Unix-style path and all of the backslashes will be translated into forward slashes. This will only take effect if the platform is Windows.
  • ${myPassword.password}: The .password suffix is used to mark a variable as a password to be hidden in the logs. This way, you can use a password as an argument in a <runProgram> action and log the execution without showing the plain text password. For example, the following action: 

     <setInstallerVariable name="pass" value="myhiddenpassword!"/>
     <runProgram>
         <program>mysql</program>
         <programArguments>-u root --password=${pass.password}</programArguments>
     </runProgram>

will be logged as:

Executing mysql -u root --password=****
Script exit code: 0

Please note this suffix is only considered when resolving variables that will be used when writing to the installation log or in the error messages thrown by the <runProgram> and <setInstallerVariableFromScriptOutput> actions. For example, <logMessage> will interpret the suffix when logging its information but <writeFile> will ignore it.

  • ${myVariable.escape_backslashes}: This will escape all of the backslashes in the text stored in the variable. It is especially useful for substitution of values in Java property files.
  • ${installdir.dos.unix.escape_backslashes}: The modifiers can be combined.

The below table summarizes all the suffixes:

Original value

Modifier

Resolved value

alongfilename.txt

${installdir.dos}

ALONGF~1.TXT

c:\Program Files\myFile.exe

${installdir.unix}

c:/Program Files/myFile.exe

c:\Program Files\myFile.exe

${myVariable.escape_backslashes}

c:\\Program Files\\myFile.exe

c:\Program Files\myLongFile.exe

${installdir.dos.unix}

C:/PROGRA~1/MYLONG~1.EXE

[Note]Convert forward slashes to backslashes

InstallBuilder does not have a modifier suffix to convert forward slashes to backslashes the same way as the .unix suffix does. To achieve the same result you just have to use a <setInstallerVariableFromRegEx> action:

 <setInstallerVariableFromRegEx>
    <name>backslash_path</name>
    <pattern>/</pattern>
    <substitution>\</substitution>
    <text>${forwardslash_path}</text>
 </setInstallerVariableFromRegEx>

The above will store the backslash-version of the Unix-like ${forwardslash_path} in the backslash_path variable.

4.3. Accessing Environment Variables

It is possible to access any environment variable using the ${env(varname)} construct, where varname is the name of an environment variable. For example, on Windows you can refer to the system drive with ${env(SYSTEMDRIVE)} and, on Linux, Mac OS X and other Unix systems to the user home directory with ${env(HOME)}

To get a list of the environment variables on your system that will be available to the installer you can execute:

  • On Windows Systems: Open a command window and execute: set
  • On Unix Systems: Open a console and execute: env

Both commands will print a list of the defined environment variables. However, you must take into account that some of these variables could vary from one machine to another.

4.4. Advanced syntax

Almost all of the elements of an InstallBuilder project can be accessed and modified as variables. This makes InstallBuilder a very versatile tool because it allows installers to customize themselves at runtime, based on the environment or on end user feedback. The three basic elements which can be accessed are:

Project properties

All of the project properties such as <version>, <shortName>, <installerFilename> and so on, can be referenced using the notation ${project.property}. For example, ${project.shortName} for the <shortName>. Similarly to regular variables, you can use any capitalization when referencing an element. Using ${PrOjEct.InstallerFilename} is equivalent to using ${project.installerFilename}.

The below example changes the <installationType> at runtime to perform an upgrade if the previous installed version, stored in an environment variable, is lower than the current one:

<project>
   ...
   <shortName>myProduct</shortName>
   <installationType>normal</installationType>
   ...
   <initializationActionList>
     <setInstallerVariable>
       <name>project.installationType</name>
       <value>upgrade</value>
       <ruleList>
         <!-- Check that the env variable exists -->
         <compareText>
            <text>${env(MYPRODUCT_VERSION)}</text>
            <logic>does_not_equal</logic>
            <value></value>
         </compareText>
         <!-- Compare the versions -->
         <compareVersions>
            <version1>${project.version}</version1>
            <logic>greater</logic>
            <version2>${env(MYPRODUCT_VERSION)}</version2>
         </compareVersions>
       </ruleList>
     </setInstallerVariable>
   </initializationActionList>
   ...
</project>

You can refer to the Project Properties appendix for the complete list of properties.

Components

Using this notation you can also modify component settings:

  • ${project.component(default).selected}
  • ${project.component(mysql).show}

This allows, for example, disabling components at runtime when the user does not provide a license key:

<stringParameter>
  <name>licenseKey</name>
  <description>Please provide a license key. If you leave the field empty
  you just will be able to test the basic functionality</description>
  <insertBefore>components</insertBefore>
  <postShowPageActionList>
    <actionGroup>
      <actionList>
        <setInstallerVariable>
          <name>project.component(premiumComponent).selected</name>
          <value>0</value>
        </setInstallerVariable>
        <setInstallerVariable>
          <name>project.component(premiumComponent).canBeEdited</name>
          <value>0</value>
        </setInstallerVariable>
      </actionList>
      <ruleList>
        <compareText>
          <text>${licenseKey}</text>
          <logic>equals</logic>
          <value></value>
        </compareText>
      </ruleList>
    </actionGroup>
  </postShowPageActionList>
</stringParameter>

You can refer to the Components appendix for the complete list of properties.

Parameters

Using the advanced syntax on parameters will allow you to modify not only their values but their entire set of properties such as <description>, <explanation> and the especially useful <ask>. The basic usage is:

${project.parameter(nameOfTheParameter).propertyName}

For example:

  • ${project.parameter(installdir).value}
  • ${project.parameter(tomcat).description}
  • ${project.parameter(mySQL).default}

If the parameter to access is a child of a <parameterGroup>, the parent must also be specified. For example, the port parameter in the below code:

<project>
  ...
  <parameterList>
    <parameterGroup>
      <name>mysqlConfiguration</name>
      <parameterList>
        <stringParameter name="port" description="MySQL port" value="3306"/>
        <passwordParameter name="password" description="MySQL root password" value=""/>
        ...
      </parameterList>
    </parameterGroup>
  </parameterList>
  ...
</project>

Can be accessed using:

${project.parameter(mysqlConfiguration).parameter(port).value}

If the parameters are also included inside a component, instead of directly under the <project> <parameterList>, it must be also specified. For example, reusing the above example:

<project>
  ...
  <componentList>
    <component>
      <name>mySQL</name>
      <parameterList>
        <parameterGroup>
          <name>mysqlConfiguration</name>
          <parameterList>
            <stringParameter name="port" description="MySQL port" value="3306"/>
            <passwordParameter name="password" description="MySQL root password" value=""/>
            ...
          </parameterList>
        </parameterGroup>
      </parameterList>
    </component>
  </componentList>
  ...
</project>

The parameter should now be accessed using:

${project.component(mysql).parameter(mysqlConfiguration).parameter(port).value}

You can use this functionality to disable pages or parameters at runtime based on the user input:

<project>
  ...
  <componentList>
   <component>
     <name>mySQL</name>
     <parameterList>
       <booleanParameter>
         <name>enableAdvanced</name>
         <description>Do you want to enable the advanced configuration?</description>
         <postShowPageActionList>
           <!-- Enable the page, which is disabled by default -->
           <setInstallerVariable>
             <name>project.component(mySQL).parameter(mysqlAdvanced).ask</name>
             <value>1</value>
             <ruleList>
                <isTrue value="${project.component(mySQL).parameter(enableAdvanced).value}"/>
             </ruleList>
           </setInstallerVariable>
         </postShowPageActionList>
       </booleanParameter>
       <parameterGroup>
          <name>mysqlAdvanced</name>
          <parameterList>
             <stringParameter name="mysqlPort" description="MySQL port" value="3306"/>
             <passwordParameter name="mysqlPassword" description="MySQL root password" value=""/>
             ...
          </parameterList>
       </parameterGroup>
     </parameterList>
   </component>
  </componentList>
  ...
</project>

Parameters are also handy when you want to preserve variables defined at build time. Accessing a variable defined in the <preBuildActionList> at runtime will result in an ***unknown variable varName*** error. To workaround this issue, you could use a hidden parameter (setting ask="0"), that won’t be displayed in the help menu nor the installer pages. For example, to pass a random generated key for each of the built installers you could use the below code:

<project>
  ...
  <parameterList>
    ...
    <stringParameter name="build_identifier" value="" ask="0"/>
    ...
  </parameterList>
  <preBuildActionList>
     <!-- Create random identifier for the build -->
     <generateRandomValue>
       <variable>build_identifier</variable>
     </generateRandomValue>
     <!-- Date of the build -->
     <createTimeStamp>
        <variable>timestamp</variable>
     </createTimeStamp>
     <!-- Register the build information in a local file -->
     <addTextToFile>
        <file>${build_project_directory}/builds</file>
        <text>${build_identifier} - Product Version: ${project.version} - IB Version: ${installer_builder_version} - Built On: ${timestamp}</text>
     </addTextToFile>
  </preBuildActionList>
  ...
</project>

As you are using a hidden parameter, the ${build_identifier} will be available at runtime and you could, for example, send it to your server using an <httpPost> action to register the installations for each release:

  <postInstallationActionList>
     ...
     <httpPost url="http://www.example.com/register.php" filename="${installdir}/activationUrl">
        <queryParameterList>
           <queryParameter name="build_identifier" value="${build_identifier}"/>
           <queryParameter name="version" value="${project.version}"/>
        </queryParameterList>
     </httpPost>
  </postInstallationActionList>
[Note]Accessing a parameter as a regular variable

If you try to access a parameter as if it were a regular variable, it will give you its value. That is, using ${installdir} or ${project.parameter(installdir).value} will return the same result.

The advantage of using the long notation is that it provides a very descriptive path to the element you are modifying. For example, if you are working with a very big project that is maintained by multiple developers and divided into multiple files using the <include> directive, locating where the below values are located could be troublesome (they could be parameters or regular variables, located in any of the included files or the main project):

   <throwError text="You have selected strict password checking and your password is too short" >
     <ruleList>
       <isTrue value="${enableStrictChecking}"/>
       <compareTextLength>
         <text>${password}</text>
         <logic>less</logic>
         <length>${minLength}</length>
       </compareTextLength>
     </ruleList>
   </throwError>

Where using the long location will point you directly to where they are defined (assuming the included files are named according to the component names, for example):

   <throwError text="You have selected strict password checking and your password is too short" >
     <ruleList>
       <isTrue value="${project.component(settings).parameter(basicConfiguration).parameter(enableStrictChecking).value}"/>
       <compareTextLength>
         <text>${password}</text>
         <logic>less</logic>
         <length>${project.component(settings).parameter(defaultPasswordSettings).parameter(minLength).value}</length>
       </compareTextLength>
     </ruleList>
   </throwError>

In addition to the above-mentioned elements, any other tag in the XML project with a unique identifier can be referenced. For example, is possible to reference a folder in a component to get its destination:

`<showInfo text="${project.component(mysql).folder(mysqlConfig).destination}"/>`

But not a file in its <distributionFileList> because files do not have a unique name.

4.5. Accessing Language Strings

You can also access language strings, either built-in or user-defined (check the Languages section for more details), using the special notation ${msg(stringKey)}. It will be resolved to the localized string identified by the key stringKey in the current installation language:

   <showInfo text="${msg(hello.world)}"/>

If you have defined the hello.world localized string in the <customLanguageFileList>, depending on the installation language you will get results such as Hello world!, Hola Mundo! or Hallo Welt.

4.6. Escaping Variables

In some cases, for example when modifying shell scripts programmatically, you may need a literal ${foo} instead of the contents of the foo variable (which may result in an ***unknown variable foo***). For these cases, InstallBuilder implements a special notation to specify that you want the text treated literally, without trying to be resolved: ${'${variableName}'}.

For example, ${'${foo}'} will be resolved to: ${foo}. More complex text can be escaped as shown in the snippet below:

     <writeFile>
       <path>~/.bashrc</path>
        <text>${'
PATH=${PATH}:/some/path
Foo=${bar}
'}</text>
     </writeFile>

It will write:

PATH=${PATH}:/some/path
Foo=${bar}

As shown in the example, it accepts line breaks in the text to escape. The only limitation is that it cannot contain the characters '} in the text to escape or it will be interpreted as the end of the escaped reference.

4.7. Nested Variables

Nested variables are also allowed. They will be evaluated from the most inner reference:

     <showInfo>
       <text>${text_${foo-${i}}_${bar}}</text>
     </showInfo>

This feature is especially useful when iterating using a <foreach> action. For example, if you have a list of component names and you want to create a list with those that are selected:

<setInstallerVariable name="selectedComponents" value=""/>
<foreach variables="component" values="componentA componentB componentC componentD">
   <actionList>
      <setInstallerVariable name="slectedComponents" value="${selectedComponents} ${component}" >
         <ruleList>
            <isTrue value="${project.component(${component}).selected"/>
         </ruleList>
      </setInstallerVariable>
  </actionList>
</foreach>

4.8. Built-in variables

InstallBuilder also provides a list of built-in variables containing information about the installer or the environment in which it is executed:

HTTP

  • installer_http_code: Contains the HTTP status code of the last httpGet or httpPost action.

    Example values:
    200, 404, 500

  • installer_http_proxy: Contains the configured HTTP proxy address

    Example values:
    http://example.org:8080/proxy

Java

  • java_autodetected: Whether or not a valid Java was autodetected

    Possible values:
    0, 1

  • java_bitness: Autodetected Java bitness

    Possible values:
    64, 32

  • java_executable: Location of the autodetected Java executable

    Example values:
    /usr/bin/java, c:/Program Files/Java/jre1.6.0_10/bin/java.exe

  • java_vendor: Autodetected Java vendor

    Possible values:
    IBM, Sun, Any

  • java_version: Autodetected Java version

    Example values:
    1.6.0, 1.5.0

  • java_version_full: Autodetected Java full version

    Example values:
    1.6.0_07, 1.5.0_11

  • java_version_major: Autodetected Java major version

    Example values:
    1.6, 1.5

  • javaw_executable: Autodetected javaw executable path

    Example values:
    /usr/bin/java, c:/Program Files/Java/jre1.6.0_10/bin/java.exe

  • javaws_executable: Location of the autodetected Java Web Start executable

    Example values:
    /usr/bin/javaws, c:/Program Files/Java/jre1.6.0_10/bin/javaws.exe

User Interface

  • installer_interactivity: The level of interactivity of the installation mode

    Possible values:
    none, minimal, minimalWithDialogs, normal

  • installer_ui: The mode in which the installer is run

    Possible values:
    text, gui, unattended

  • installer_ui_detail: The detailed mode in which the installer is run

    Possible values:
    text, gtk, qt, osx, win32, xwindow, unattended

.NET Framework

  • dotnet_autodetected: Whether or not a valid .NET framework was autodetected

    Possible values:
    0, 1

  • dotnet_framework_type: .NET framework type

    Possible values:
    , client, full

  • dotnet_version: .NET framework version

    Example values:
    2.0, 3.5, 4.0, 4.5

Installer

  • installation_aborted_by_user: Whether or not installation was manually aborted by user

    Possible values:
    0, 1

  • installation_finished: Whether or not the installation finished successfully

    Possible values:
    0, 1

  • installation_guid: Unique installation ID

    Example values:
    253d2272-b35a-409a-661e-f202473c3a0d

  • installation_language_code: Language code of the installation

    Possible values:
    sq, ar, es_AR, az, eu, pt_BR, bg, ca, hr, cs, da, nl, en, et, fi, fr, de, el, he, hu, id, it, ja, kk, ko, lv, lt, no, fa, pl, pt, ro, ru, sr, zh_CN, sk, sl, es, sv, th, zh_TW, tr, tk, va, vi, cy

  • installer_builder_timestamp: Timestamp of the InstallBuilder used to build the installer

    Example values:
    201001220702

  • installer_builder_version: Version of InstallBuilder used to build the installer

    Example values:
    6.2.7

  • installer_command_line_arguments: Command line arguments as passed to installer

    Example values:
    --mode gtk, --installdir /opt/app-1.0

  • installer_error_message: Contains the error of the last failed action, possibly masked by its <customErrorMessage>

    Example values:
    Unknown error installing MySQL

  • installer_error_message_original: Contains the original error of the last failed action

    Example values:
    Unknown error executing action
  • installer_exit_code: Installer Exit Code value. It’s value is 0 by default and set to 1 if there was an error executing an action.

  • installer_installation_log: The location of the installer log

    Example values:
    /tmp/bitrock_install.log, C:\Users\Username\Appdata\Local\Temp

  • installer_is_root_install: Whether or not the current user has root privileges

    Possible values:
    0, 1

  • installer_package_format: Type of installer

    Possible values:
    executable

  • installer_pid: PID of the running installer or uninstaller

    Example values:
    53008

  • program_exit_code: Exit code from program; set by runProgram and setInstallerVariableFromScriptOutput actions

    Example values:
    0, 1

  • program_stderr: Program’s error output; set by runProgram and setInstallerVariableFromScriptOutput actions

    Example values:

  • program_stdout: Program’s output; set by runProgram and setInstallerVariableFromScriptOutput actions

    Example values:

  • required_diskspace: Required disk space to install the application in Kilobytes

    Example values:
    10000, 25000

Windows Folders

  • windows_folder_program_files: Directory for program files

    Example values:
    C:\Program Files

  • windows_folder_program_files_common: Directory for components shared across applications

    Example values:
    C:\Program Files\Common Files

  • windows_folder_system: Windows system directory

    Example values:
    C:\Windows\system32

  • windows_folder_systemroot: Windows root directory

    Example values:
    C:\Windows

  • windows_folder_windows: Windows root directory

    Example values:
    C:\Windows

Windows Folders - System Scope

  • windows_folder_common_admintools: Directory that stores administrator tools for all users

    Example values:
    C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools

  • windows_folder_common_appdata: Directory that stores common application-specific data

    Example values:
    C:\ProgramData

  • windows_folder_common_desktopdirectory: Directory that stores common desktop files

    Example values:
    C:\Users\Public\Desktop

  • windows_folder_common_documents: Directory that stores common document files

    Example values:
    C:\Users\Public\Documents

  • windows_folder_common_favorites: Directory that stores common favorite items

    Example values:
    C:\Users\Administrator\Favorites

  • windows_folder_common_music: Directory that stores common music files

    Example values:
    C:\Users\Public\Music

  • windows_folder_common_pictures: Directory that stores common picture files

    Example values:
    C:\Users\Public\Pictures

  • windows_folder_common_programs: Directory that stores common program groups in start menu

    Example values:
    C:\ProgramData\Microsoft\Windows\Start Menu\Programs

  • windows_folder_common_startmenu: Directory that stores common start menu items

    Example values:
    C:\ProgramData\Microsoft\Windows\Start Menu

  • windows_folder_common_startup: Directory that stores common Startup program group

    Example values:
    C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

  • windows_folder_common_templates: Directory that stores common templates

    Example values:
    C:\ProgramData\Microsoft\Windows\Templates

  • windows_folder_common_video: Directory that stores common video files

    Example values:
    C:\Users\Public\Videos

Cross-platform Folders

  • installdir: The installation directory

    Example values:
    /home/user/programx, C:\Program Files\programx

  • installer_directory: The directory location of the installer binary

    Example values:
    /home/user/example, C:\example

  • installer_pathname: The full path of the installer binary

    Example values:
    /home/user/example/installer.bin, C:\example\installer.exe

  • platform_install_prefix: The platform specific default installation path

    Example values:
    /home/user, C:\Program Files, /Applications

  • system_temp_directory: Path to the system’s temporary directory

    Example values:
    /tmp, C:\Users\Username\Appdata\Local\Temp

  • user_home_directory: Path to the home directory of the user who is running the installer

    Example values:
    /home/username, C:\Users\Username

Build-time Variables

  • build_project_directory: Directory containing the XML project used to generate the installer.

    Example values:
    /home/username/installbuilder-7.0.0/projects, C:\Program Files\Bitrock InstallBuilder for Windows 7.0.0\projects

  • installbuilder_install_root: Installation directory of InstallBuilder. This variable is available only at build time, as it does not make sense to access this information at runtime

    Example values:
    /home/username/installbuilder-7.0.0, C:\Program Files\Bitrock InstallBuilder for Windows 7.0.0

  • installbuilder_output_directory: InstallBuilder output directory. This variable is available only at build time, as it does not make sense to access this information at runtime

    Example values:
    /home/username/installbuilder-7.0.0/output, C:\Program Files\Bitrock InstallBuilder for Windows 7.0.0\output

  • installbuilder_output_filename: Location of the generated installer. This variable is available only at build time, as it does not make sense to access this information at runtime

    Example values:
    /home/username/installbuilder-7.0.0/output/sample-1.0-linux-installer.run, C:\Program Files\Bitrock InstallBuilder for Windows 7.0.0\output\sample-1.0-window-installer.exe

  • installbuilder_ui: The mode in which the builder is run

    Possible values:
    text, gui

Windows Folders - User Scope

  • windows_folder_admintools: Directory that stores administrator tools for individual user

    Example values:
    C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Administrative Tools

  • windows_folder_appdata: Directory that stores user application-specific data

    Example values:
    C:\Users\Administrator\AppData\Roaming

  • windows_folder_cookies: Directory that stores user cookies

    Example values:
    C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Cookies

  • windows_folder_desktopdirectory: Directory that stores user desktop files

    Example values:
    C:\Users\Administrator\Desktop

  • windows_folder_favorites: Directory that stores user favorite items

    Example values:
    C:\Users\Administrator\Favorites

  • windows_folder_history: Directory that stores user Internet history items

    Example values:
    C:\Users\Administrator\AppData\Local\Microsoft\Windows\History

  • windows_folder_internet_cache: Directory that stores user temporary internet files

    Example values:
    C:\Users\Administrator\AppData\Local\Microsoft\Windows\Temporary Internet Files

  • windows_folder_local_appdata: Directory that stores user local (non-roaming) repository for application-specific data

    Example values:
    C:\Users\Administrator\AppData\Local

  • windows_folder_mymusic: Directory that stores user music files

    Example values:
    C:\Users\Administrator\Music

  • windows_folder_mypictures: Directory that stores user picture files

    Example values:
    C:\Users\Administrator\Pictures

  • windows_folder_myvideo: Directory that stores user video files

    Example values:
    C:\Users\Administrator\Videos

  • windows_folder_nethood: Directory that stores user network shortcuts

    Example values:
    C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Network Shortcuts

  • windows_folder_personal: Directory that stores user document files

    Example values:
    C:\Users\Administrator\Documents

  • windows_folder_printhood: Directory that stores printer shortcuts

    Example values:
    C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Printer Shortcuts

  • windows_folder_profile: Directory that stores user profile

    Example values:
    C:\Users\Administrator

  • windows_folder_programs: Directory that stores user program groups in start menu

    Example values:
    C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs

  • windows_folder_recent: Directory that stores shortcuts to user’s recently used documents

    Example values:
    C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Recent

  • windows_folder_sendto: Directory that stores user Send To menu items

    Example values:
    C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\SendTo

  • windows_folder_startmenu: Directory that stores user start menu items

    Example values:
    C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu

  • windows_folder_startup: Directory that stores user Startup program group

    Example values:
    C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

  • windows_folder_templates: Directory that stores user templates

    Example values:
    C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Templates

Linux Specific

  • linux_distribution: Type of Linux distribution

    Possible values:
    redhat, amazon, fedora, debian, ubuntu, suse, mandrake, slackware, redflag, gentoo, arch
  • linux_distribution_codename: Linux distribution code name (based on Linux Standard Base tool: lsb_release)

  • linux_distribution_description: Linux distribution description (based on Linux Standard Base tool: lsb_release)

    Example values:
    Debian, GNU/Linux

  • linux_distribution_fullname: Linux distribution fullname

    Possible values:
    Red Hat Enterprise Linux, Red Hat Linux, CentOS, SME Server Linux, Scientific Linux, Red Hat Enterprise Linux, Red Hat Linux, CentOS, SME Server Linux, Scientific Linux, Fedora, Core, Debian, Debian, openSUSE, Suse, Mandrake, Slackware, Red, Flag, Gentoo, Arch

  • linux_distribution_id: Linux distribution distributor’s ID (based on Linux Standard Base tool: lsb_release)

    Example values:
    Debian

  • linux_distribution_release: Linux distribution release number(based on Linux Standard Base tool: lsb_release)

    Example values:
    3.1

  • linux_distribution_shortname: Linux distribution shortname

    Possible values:
    rhel, rh, amazon, fedora, debian, ubuntu, suse, mandrake, slackware, redflag, gentoo, arch

  • linux_distribution_version: Linux distribution mayor version

    Example values:
    5.0

OSX Specific

  • osx_major_version: OSX major version number

    Example values:
    10.3, 10.5

  • osx_version: OSX version number

    Example values:
    10.3.9, 10.5.7

Windows Specific

  • windows_os_family: Type of Windows OS

    Possible values:
    Windows 95, Windows NT

  • windows_os_family_shortname: Windows OS family shortname

    Possible values:
    win9x, winnt

  • windows_os_flavor: Flavor of Windows OS

    Possible values:
    Advanced Server, Business, Data Center, Enterprise, Essentials, Foundation, Home, Home Basic, Home Premium, Professional, Server, Standard, Starter, Storage Server, Storage Server Standard, Storage Server Workgroup, Ultimate, Web Edition, Workstation

  • windows_os_name: Windows OS name

    Possible values:
    Windows 7, Windows 7 WSLK, Windows 8, Windows 8.1, Windows 10, Windows 95, Windows 98, Windows 2000, Windows 2003, Windows 2008, Windows 2008 R2, Windows 2012, Windows 2012 R2, Windows 2016, Windows 2019, Windows Vista, Windows XP

  • windows_os_service_pack: Windows OS Service Pack version number

    Example values:
    1, 2, 3

  • windows_os_uac_enabled: Whether or not UAC is enabled

    Possible values:
    0, 1

  • windows_os_version_number: Windows OS version number

    Possible values:
    4.0, 4.1, 5.0, 5.1, 5.2, 6.0, 6.1, 7.0, 10.0

System Configuration

  • machine_cpu_count: Number of CPUs in the machine

    Example values:
    1, 2

  • machine_cpu_speed: The machine’s CPU speed in MHZ

    Example values:
    1500

  • machine_fqdn: The machine’s fully qualified domain name

    Example values:
    bitrock-desktop.mydomain.com

  • machine_hostname: The machine’s hostname

    Example values:
    example.com

  • machine_ipaddr: The machine’s IP address

    Example values:
    10.0.0.2

  • machine_swap_memory: The machine’s swap memory in MB

    Example values:
    512

  • machine_total_memory: The machine’s total physical memory in MB

    Example values:
    512

  • platform_exec_suffix: The platform specific binary suffix

    Possible values:
    exe, run, app

  • platform_has_smp: Whether or not the machine has multiple processors

    Possible values:
    0, 1

  • platform_name: At build-time, it contains the target build platform. At runtime, the platform in which the installer is running

    Possible values:
    windows, linux, osx

  • platform_path_separator: The platform specific path separator

    Possible values:
    \, /

  • system_locale: Current system locale

    Possible values:
    sq, ar, es_AR, az, eu, pt_BR, bg, ca, hr, cs, da, nl, en, et, fi, fr, de, el, he, hu, id, it, ja, kk, ko, lv, lt, no, fa, pl, pt, ro, ru, sr, zh_CN, sk, sl, es, sv, th, zh_TW, tr, tk, va, vi, cy

  • system_username: Name of the user who is running the installer

    Example values:
    root, Administrator, guest

Installer Page Order Control

  • back_page: The previous page to show

    Example values:
    installdir, welcome, installation, installationFinished

  • next_page: The next page to show

    Example values:
    installdir, welcome, installation, installationFinished
Prev   Next
3. Architecture Home 5. Components