# Installer Modes

Installers generated by install4j can be run in three modes:

- **GUI mode** — The default mode for installer applications is to display a GUI installer or uninstaller.
- **Console mode** — If the installer application is invoked with the -c argument, the interaction with the user is performed in the terminal from which the installer was invoked.
- **Unattended mode** — If the installer is invoked with the -q argument, there is no interaction with the user and the installation is performed automatically with the default values.

The flow of screens and action sequence is executed in the same way for all three modes. If some actions or screens should not be traversed for console or unattended installations, you can set their "Condition expression" properties to

```
!context.isConsole()
```

or

```
!context.isUnattended()
```

<a id="gui"></a>

### GUI mode

In GUI mode, the keyboard shortcut `CTRL-SHIFT-L` shows the log file in the Explorer on Windows, in the Finder on macOS and in the file manager on Linux/Unix. This shortcut is not advertised to the user, but you can communicate it to the user for debug purposes.

<a id="console"></a>

### Console mode

Installers generated by install4j can perform console installations, unless this feature has been disabled in the [application configuration](../beans/applications.md) of the "Installer->Screens & Actions" step. To start a console installation, the installer has to be invoked with the -c argument.

All standard screens and form components in install4j present their information on the console and allow the user to enter information as in the GUI installer. Not all messages on the screen are displayed in the console installer. By default, only the subtitle of a screen is displayed as the first message, but you can change this behavior with the "Console screen change handler" script of the installer application.

The subtitle is appropriate to display in console mode, because all standard screens in install4j have a question as their subtitle. If you add your own forms to the [screen sequence](../beans/screensAndActions.md), you should phrase their subtitles as questions to create a consistent user experience for the console installer.

On Windows, the information of whether an executable is a GUI executable or a console executable has to be statically compiled into the executable. Installers are GUI executables, otherwise a console would be displayed when starting the installer from the explorer. This is also the reason why the JRE supplies both the `java.exe` console executable and the `javaw.exe` GUI executable on Windows.

However, a GUI executable can attach to a console from which it was started. GUI executables are started in the background by default, which means that you have to use the `start` command to put it in the foreground and be able to enter information:

```
start /wait installer.exe -c
```

If you develop new screens or form components, you have to override the method

```
boolean handleConsole(Console console) throws UserCanceledException
```

to implement the behavior for console mode. Displaying default data on the console and requesting user input is made easy with the `Console` class that is passed as a parameter.

When the installer runs on Java 25 or later in an ANSI-capable terminal, console mode uses a "rich" renderer: status and detail rows update in place, a progress bar tracks file installation, a spinner indicates indeterminate work, and prompts (Yes/No, choice lists, multi-selection, password) are presented as interactive widgets with arrow-key navigation. The rich renderer falls back to the plain line-by-line console automatically when the terminal reports as "dumb" (e.g. when stdout is redirected to a file or piped to another process), or when the project's Java minimum version is below 25.

You can force the plain console renderer regardless of terminal capability by passing -J-Dinstall4j.plainConsole=true to the installer. This is useful for automated testing of the plain code path, or as an escape hatch if the rich renderer misbehaves in an unusual terminal.

<a id="unattended"></a>

### Unattended mode

Installers generated by install4j can perform unattended installations, unless this feature has been disabled on the [application configuration](../beans/applications.md) of the "Installer->Screens & Actions" step. To start an unattended installation, the installer has to be invoked with the -q argument. The installer will perform the installation as if the user had accepted all default settings.

There is no user interaction on the terminal. In all cases, where the installer would have asked the user whether to overwrite an existing file, the installer will not overwrite it. You can change this behavior by passing -overwrite as a parameter to the installer. In this case, the installer will overwrite such files. For the standard case, it is recommended to fine-tune the overwrite policy in the [distribution tree](../concepts/files.md) instead, so that this situation never arises.

The installer will install the application to the default installation directory, unless you pass the -dir parameter to the installer. The parameter after -dir must be the desired installation directory, for example:

```
installer.exe -q -dir "D:\MyApps\My Application"
```

For the unattended mode of an installer, [response files](responseFile.md) are an important instrument to pre-define user input.

On Windows, the output of the installer is not printed to the command line for unattended installation. If you pass the -console parameter after the -q parameter, the executable will try to connect to the invoking console and display output to the user. This is useful for debugging purposes.

If the installation was successful, the exit code of the installer will be 0, if no suitable JRE could be found it will be 83 and for other types of failures it will be 1.

If you develop new screens or form components, you have to override the method

```
boolean handleUnattended()
```

in order to support unattended installations.
