# Initialization

During initialization, fvwm searches for a configuration file which describes key and button bindings, and many other things. The format of these files is described later. Fvwm first searches for configuration files using the command

     config

This looks for file `config` in `$FVWM_USERDIR` and `$FVWM_DATADIR` directories, as described in . If this fails more files are queried for backward compatibility. Here is the complete list of all file locations queried in the default installation (only the first found file is used):

- `$HOME`/.fvwm/config
- /usr/local/share/fvwm/config

- `$HOME`/.fvwm/.fvwm2rc
- `$HOME`/.fvwm2rc
- /usr/local/share/fvwm/.fvwm2rc
- /usr/local/share/fvwm/system.fvwm2rc
- /etc/system.fvwm2rc

Please note, the last 5 locations are not guaranteed to be supported in the future.

If a configuration file is not found, the left mouse button, or Help or F1 keys on the root window bring up menus and forms that can create a starting configuration file.

Fvwm sets two environment variables which are inherited by its children. These are `$DISPLAY` which describes the display on which fvwm is running. `$DISPLAY` may be unix:0.0 or :0.0, which doesn't work too well when passed through ssh to another machine, so `$HOSTDISPLAY` is set to a network-ready description of the display. `$HOSTDISPLAY` always uses the TCP/IP transport protocol (even for a local connection) so `$DISPLAY` should be used for local connections, as it may use Unix-domain sockets, which are faster.

If you want to start some applications or modules with fvwm, you can simply put

     app

or

     FvwmXxx

into your `config`, but it is not recommended; do this only if you know what you are doing. It is usually important to start applications or modules after the entire config is read, because it contains styles or module configurations which can affect window appearance and functionality.

The standard way to start applications or modules on fvwm's start up is to add them to an initialization function (usually StartFunction or InitFunction). This way they are only started after fvwm finishes to read and execute `config` file.

Fvwm has three special functions for initialization: StartFunction, which is executed on startups and restarts; InitFunction and RestartFunction, which are executed during initialization and restarts (respectively) just after StartFunction. These functions may be customized in a user's `config` file using the command (described later) to start up modules, xterms, or whatever you'd like to have started by fvwm.

Fvwm has also a special exit function: ExitFunction, executed when exiting or restarting before actually quitting. It could be used to explicitly kill modules, etc.

If fvwm is run under a session manager, functions SessionInitFunction and SessionRestartFunction are executed instead of InitFunction and RestartFunction. This helps to define the user's `config` file to be good for both running under a session manager and without it. Generally it is a bad idea to start xterms or other applications in "Session*" functions. Also someone can decide to start different modules while running under a session manager or not. For the similar purposes SessionExitFunction is used instead of ExitFunction.

     StartFunction
     StartFunction
     + I   * *
     + I

     InitFunction
     InitFunction
     + I
     + I
     + I  xsetroot -solid cyan
     + I  xterm
     + I  netscape

     RestartFunction
     RestartFunction
     + I

     SessionInitFunction
     SessionInitFunction
     + I

     SessionRestartFunction
     SessionRestartFunction
     + I

You do not need to define all special functions if some are empty. Also note, all these special functions may be emulated now using StartFunction and ExitFunction, like this:

     StartFunction
     StartFunction
    + I  (Init)
    + I   * *
    + I  (Restart)

     ExitFunction
     ExitFunction
    + I  (Quit)  Bye-bye
    + I  MyBuggyModule
    + I  (ToRestart)