XSESSION(1)

📦 version 1.1, in opensuse-leap 16.0

🦋 XSESSION 💅

(that's XSESSION(1) bestie — General Commands Manual, we're in the big leagues)

✨ NAME ✨

xsession — session manager for the X Window System 🪟👑

🎀 SYNOPSIS 🎀

xsession [-toolkitoption ...] [-console] [-cpp] [-defaultWM ...] [-D...]
[-m4] [-keep] [-notify] [-remote] [-sounds] [-split] [-startup]
[-version] [-help]

🌸 DESCRIPTION 🌸

Okay so picture this: xsession is a session manager. That's the whole vibe. It's normally executed by your ~/.xinitrc (or ~/.xsession) script, and it controls your entire X Window session. The second it starts up, it launches a window manager plus whatever applications you picked, like a little entourage. 💁‍♀️ And the best part? At any time during your session you can switch to a different window manager or run other applications straight from the xsession menus. You can also lock your screen with an independent locker application, and redirect the messages that usually go to /dev/console over to the xsession window. Iconic behavior honestly.

One genuinely useful feature of xsession is the preprocessing of window managers' configuration files. When a window manager gets launched, its startup file can be filtered through m4(1) or cpp(1). Some macros are defined (like the host name, screen size, and so on) that help you customize your menus and screen layout. The big win here: several window managers can share the same startup file. For example, you can (and they do) use the same file for mwm(1) (Motif), twm(1), ctwm(1) and vtwm(1). Some lines are protected by a test on the WM_NAME macro, but the other lines are common. This saves a lot of time if you want to maintain the same menu structure for all four of them. You can also use include statements in your file. 🧚

The best way to execute xsession? Put it in your ~/.xinitrc (or ~/.xsession) file, as the last client. The xinit(1) manual page says that the last long-lived program started [...] should be left in the foreground so that the script won't exit. You'll find a similar statement in the xdm(1) manual page. That last program should be xsession. And honestly? It might even be the only program executed in your startup file, because xsession itself provides a way to launch other applications. When it starts, xsession looks in your home directory and executes a file named .X11Startup, if found. That shell script is what starts your client programs. Slay. ✨

💅 OPTIONS 💅

XSession accepts all of the standard X Toolkit command line options (like -iconic, -geometry and so on; see X(1)). The following additional arguments are supported too. Quick heads up though: because the standard X Toolkit method is used to retrieve X resources, most of these command line options are really just another way to set the value of some resources. These options always take precedence over their corresponding resources. Periodt. 👑

  • -console — When -console is set, xsession tries to redirect the console output messages to its window. This feature should work on most systems, but it may be necessary that xsession is setuid to root. 🙈
  • -defaultWM window-manager's-short-name — Specifies the (short) name of the default window manager to launch. See the Menu customization section below for details. The easiest way to choose your default window manager is by using X resources in your ~/.Xdefaults file (or the file you read with xrdb(1)). The default value is TWM.
  • -keep — Sets the keepTmpFile resource to true. This one is used mainly for debugging purposes. 🐛
  • -notify, -nonotify — When a message is printed in the xsession window and -notify is set, the icon name of the application has * appended to it, so it's obvious even when the application is iconified. When the application is de-iconified, the icon name gets restored to its initial value. The -notify option is set by default. 🔔
  • -preprocessor m4|cpp — Specifies which preprocessor must be used. Only two values may be used: either m4 or cpp, according as you want to use m4(1) or cpp(1). The default value is m4.
  • -quiet — If you use this option, xsession will not print any messages when an application or window manager is started. The warning messages (e.g. configuration file not found) will not be displayed either. 🤫
  • -remote — You should set this option if you run xsession on a remote host (e.g. if your ~/.xinitrc or ~/.xsession file tests if you're on an oldish machine and, if so, executes xsession on a more powerful host in a remote shell). XSession must then execute a special exit code to work around an unwanted feature in rsh(1) that prevents it from exiting if there's one or more children of xsession alive. This exit code shuts down the socket associated with the remote connection. 🛰️
  • -sounds, -nosounds — Activates (or disables) the sounds. The sounds will only be available if xsession was compiled with SOUNDS defined. The sounds are activated by default if SOUNDS was defined, and they're disabled otherwise. 🔊
  • -split, -nosplit — When -split and -console are set, the output messages of the programs and the ones related to the console are shown in separate windows. The -split option is set by default, but it will be silently ignored if the console option is not used. 🪟🪟
  • -startup, -nostartup — If -startup is set, then the user's .X11Startup file is executed by xsession at startup. You might want to turn this option off for debugging purposes, or if you don't have a .X11Startup file. The -startup option is set by default. 🚀
⚠️ Note: if you use a + instead of a - in the boolean options above, then the effect will be reversed (e.g. +startup is the same as -nostartup). Don't say I didn't warn you bestie 💀

There is no X resource equivalent for the following command line options:

  • -Dsymbol — This defines a symbol for the preprocessor that's run on the window managers' configuration files. All instances of symbol in the configuration files will be replaced by the NULL string (if xsession was compiled with USE_M4 defined) or 1 (if xsession was compiled with USE_CPP).
  • -Dsymbol=value — This defines a symbol for the preprocessor that's run on the window managers' configuration files. All instances of symbol in the configuration files will be replaced by value.
  • -cpp, -m4 — These options are equivalent to -preprocessor cpp and -preprocessor m4, respectively.
  • -help — Guess what? 😏
  • -version — Prints the current version number and exits. 👋

🌈 X DEFAULTS 🌈

This program uses mainly the Text, Paned, Box, MenuButton and SimpleMenu Athena widgets. Look in the Athena Widget Set documentation for controlling them. See also the Application resources section in this manual page. 📚

👑 WIDGETS 👑

In order to specify resources, it's useful to know the hierarchy of the widgets which compose xsession. In the notation below, indentation indicates hierarchical structure. The widget class name is given first, followed by the widget instance name. 🧬

     XSession  xsession
          Paned  top_pane
               Box  menu_box
                    MenuButton  session_button
                         SimpleMenu  menu
                              SmeBSB  lock_menu_item
                              SmeBSB  quit_menu_item
                    MenuButton  wm_button
                         SimpleMenu  menu
                              SmeBSB  <window manager's short name>_menu_item
                              .
                              . (one for each window manager)
                              .
                    MenuButton  app_button
                         SimpleMenu  menu
                              SmeBSB  <application's short name>_menu_item
                              .
                              . (one for each application)
                              .
                    MenuButton  misc_button
                         SimpleMenu  menu
                              SmeBSB  clear_menu_item
                              SmeBSB  clear2_menu_item
               Text  ascii_text
               Text  ascii_text2

The <window manager's short name> and <application's short name> represent the short name of the program (a window manager or another application). For example, if you have TWM in your Window Managers menu, you'll have a SmeBSB instance named TWM_menu_item. 🎯

🎀 APPLICATION RESOURCES 🎀

Okay bestie, xSession has its own little stash of application-specific resources so you can customize stuff just for xsession. Some of these have command-line equivalents that can override them — iconic override behavior, no cap.

You can also pass any of these on the command line using the X Toolkit Intrinsics resource specification mechanism. For example, to run xsession using xlock(1) to lock the screen:

% xsession -xrm '*lockCommand:xlock -mode random'
  • allowBell (class AllowBell) — set it to true or false. When it’s true, xsession rings the bell if a message printed in its window contains one or more bell character(s). This can happen if the output from an application launched from the menu contains those characters — like in an error message, fr fr. Default: false.
  • appNames (class AppNames) — a comma-separated list of the short names of the applications shown in the Applications menu. Peep the Menu customization section below for the whole deal on names and short names. The default should have been customized for your site during xsession installation. The names inside this resource are used as <application_name> to build the resource names right below this one.
  • app_<application_name> (class App_<application_name>) — each one is a string with the full application name, then a comma, then the command to execute that application. See Menu customization below for how to build these. It’s giving “custom menu, but make it exact.”
  • console (class Console) — set it to true or false. If true, xsession tries to redirect console output messages to its window. This feature should work on most systems, but it may be necessary for xsession to be setuid to root. Default: false.
  • defaultWM (class DefaultWM) — the short name of the default window manager to launch. See Menu customization below for the details. Default: TWM.
  • keepTmpFile (class KeepTmpFile) — set it to true or false. If true, xsession will not delete the temporary files created for the preprocessor and the window manager. This only makes sense if you use a preprocessor — like m4(1) or cpp(1) — to filter the window manager’s configuration file. This option is mainly for debugging purposes. Default: false.
  • lockCommand (class LockCommand) — the command to execute when the user selects the Lock entry in the Session menu. The string can contain space characters so you can add arguments to the command. Default: xscreensaver-command -lock.
  • motd (class Motd) — set it to true or false. When true, the content of the /etc/motd file is printed in the xsession window at startup. Default: true.
  • notify (class Notify) — set it to true or false. When a message is printed in the xsession window and this resource is true, the icon name of the application has * appended, so it’s evident even when the application is iconified. When the application is de-iconified, the icon name is restored to its initial value. Default: true.
  • preprocessor (class Preprocessor) — specifies which preprocessor must be used. Only two values may be used: m4 or cpp, depending on whether you want to use m4(1) or cpp(1). Default: m4.
  • quiet (class Quiet) — set it to true or false. If true, xsession will not print any messages when an application or window manager is started. The warning messages — e.g. configuration file not found — will not be displayed either. Default: false.
  • remote (class Remote) — set it to true or false. The usual way to change this value is by using a command line option, not an X resource. Default: false.
  • ringBell (class RingBell) — set it to true or false. When a message is printed in the xsession window and this resource is true, the bell is rung so the user is warned even if the window is not visible. Default: false.
  • sounds (class Sounds) — set it to true or false. If this resource is false, then the sounds are disabled. The sounds will only be available if xsession was compiled with SOUNDS defined. Default: true if SOUNDS was defined, else false.
  • splitWindow (class SplitWindow) — set it to true or false. If both this resource and the console resource are true, the normal output messages of the programs and the ones related to the console are shown in separate windows. Default: true.
  • startup (class Startup) — set it to true or false. If true, then the user’s .X11Startup file is executed by xsession at startup. You may want to turn this off for debugging purposes or if you don’t have a .X11Startup file. Default: true.
  • wmNames (class WMNames) — a comma-separated list of the short names of the window managers shown in the Window Managers menu. See Menu customization below for details about names and short names. The default should have been customized for your site during xsession installation. The names inside this resource are used as <window_manager_name> to build the resource name below.
  • wm_<window_manager_name> (class WM_<window_manager_name>) — each one is a comma-separated list that defines the properties of a window manager. First field: the full name of the window manager. Second field: the command to execute to run this window manager. Third field (optional): the name of the configuration file that should be filtered through m4(1) or cpp(1) to produce the actual window manager’s startup file. Fourth and fifth fields (optional): these explain to xsession how the window manager can read an arbitrary file as a configuration file — this can be done using command line arguments or an environment string. See Menu customization below for how to build these resources.

If xsession was compiled with the SOUNDS symbol defined, the following extra X resources are available. See the Sounds section below for more info about using sounds in xsession. 🎧✨

  • soundStart (class SoundStart) — name of the sound file to play when xsession starts. Default: none.
  • soundEnd (class SoundEnd) — name of the sound file to play when xsession ends. Default: none.
  • soundStartWM (class SoundStartWM) — name of the sound file to play when a window manager starts. Default: none.
  • soundEndWM (class SoundEndWM) — name of the sound file to play when a window manager ends. Default: none.
  • soundStartApp (class SoundStartApp) — name of the sound file to play when an application starts. Default: none.
  • soundEndApp (class SoundEndApp) — name of the sound file to play when an application ends. Default: none.
  • soundLock (class SoundLock) — name of the sound file to play when the screen locker starts. Default: none.
  • soundNotify (class SoundNotify) — name of the sound file to play when a message is printed in the main window. Default: none.

✨ PREPROCESSING OF WINDOW MANAGERS FILES ✨

Okay so one of the most powerful features of xsession? It can filter the window managers' setup files through a preprocessor, and honestly it's giving main character energy. This is useful if you work on several machines which don't necessarily have the same characteristics, or if you wish to share a common configuration file between several window managers. You can use m4(1) or cpp(1) directives (e.g. file inclusion directives) and pre-defined symbols to customize your environment at runtime. XSession uses either m4(1) or cpp(1) to pre-process the setup files, according to the value of the preprocessor resource.

When xsession starts a new window manager, it creates a temporary file for the preprocessor. This file contains all symbols that will be defined and then includes the original window manager's configuration file. The preprocessor will parse that file and send its output to another temporary file. This latter file will be the actual window manager's configuration file. In order to achieve this, xsession should have a way to force the window manager into using another input file. This is usually done with a command line parameter for the window manager (such a -f name) or with an environment variable. If a window manager provides no way for doing this, you won't be able to use the preprocessing features for it. See “Menu Customization” below for details.

The following symbols are defined (most of these definitions were borrowed from the ctwm(1) manual page):

  • XSESSION_VERSION — The version number of xsession.
  • XSESSION_PID — The process number of xsession. You may use this pid to send a SIGHUP signal and terminate the session from one of the window manager's menus.
  • SERVERHOST — This variable is set to the name of the machine that is running the X server.
  • CLIENTHOST — The machine that is running the clients (i.e. the window manager and all other applications).
  • HOSTNAME — The canonical hostname running the clients (i.e. a fully-qualified version of CLIENTHOST).
  • MACHINE — The machine type of CLIENTHOST (e.g. sun4m, mips, i486, ...).
  • USER — The name of the user running the program. Gotten from the environment.
  • HOME — The user's home directory. Gotten from the environment.
  • VERSION — The X major protocol version. As seen by ProtocolVersion(3).
  • REVISION — The X minor protocol revision. As seen by ProtocolRevision(3).
  • VENDOR — The vendor of your X server. For example: MIT X Consortium.
  • RELEASE — The release number of your X server. For MIT X11R5, this is 5.
  • WIDTH — The width of your display in pixels.
  • HEIGHT — The height of your display in pixels.
  • X_RESOLUTION — The X resolution of your display in pixels per meter.
  • Y_RESOLUTION — The Y resolution of your display in pixels per meter.
  • PLANES — The number of bit planes your display supports in the default root window.
  • BITS_PER_RGB — The number of significant bits in an RGB color. (log base 2 of the number of distinct colors that can be created. This is often different from the number of colors that can be displayed at once.)
  • CLASS — The visual class of your display. It returns one of StaticGray, GrayScale, StaticColor, PseudoColor, TrueColor, DirectColor, or, if it cannot determine what you have, NonStandard.
  • COLOR — This variable is just a wrapper around the CLASS definition. It returns Yes on StaticColor, PseudoColor, TrueColor and DirectColor displays. On the other displays, it is undefined if you use cpp(1), and it returns No if you use m4(1).
  • WM_NAME — The name of the current window manager. This is useful for protecting parts of one shared setup file: you may use the same file for several window managers and protect some lines if they are understood by only one of them.
  • TWM_TYPE — Same as WM_NAME. For compatibility with ctwm(1) configuration files.

Here is a short summary of the useful directives of m4(1) and cpp(1). Please refer to their own manual pages for any additional information.

Warning: when using m4, xsession automatically inserts the following m4 directive in the temporary file:
changequote([,])

This will use the square brackets as string delimiters, instead of the default quote and backquote characters, which are probably already used in your file. Don't duplicate this directive in your file, because m4 doesn't like that...

Assigning a value to a symbol 🎀

With m4, use define(symbol, value). With cpp, use #define symbol value.

Including a file 🦋

With m4, use include(file) or sinclude(file). The sinclude directive is similar to include, except that it does not complain if the file is inaccessible. With cpp, use #include "file".

Evaluating a mathematical expression 🌸

With m4, use eval(expression). There is no equivalent for cpp.

Testing if a symbol if defined 💀

With m4, use ifdef([symbol], result1, result2), where the third argument is optional. Note that the square brackets are used to quote the symbol. If the symbol is defined, this expression returns result1, else it returns result2. With cpp, use #ifdef symbol ... #else ... #endif, where the #else ... part is optional. Each directive should be on a line by itself. If symbol is defined, then the lines between #ifdef and #else will be output. If not, then the lines between #else and #endif will be output.

Testing an expression 🧚

With m4, ifelse(expr1, expr2, result1, ...) does the following: if expr1 and expr2 are the same string, then the result of the ifelse is result1. If not, and if there are more than four arguments, the process is repeated with arguments 4, 5, 6 and so on. Otherwise, the value is either the last string not used by the above process, or NULL if it is not present. Some versions of cpp allow a similar structure with #if, but most versions do not have any equivalent.

Although m4 is less intuitive than cpp, it has more features. This is why our preferences go to m4 for preprocessing the window managers' files. See also the “Examples” section below, it shows some parts of configuration files to be preprocessed by m4.

Okay bestie, this is the fun part — the part where you make it yours. The Window Managers and Applications menus may (and honestly, should) be customized for your site using X resources. These menus get built with a whole two-stage process: first, the list of items is read from a resource, then the definition of each item gets looked up in the resource database. Two steps, no skipping 💅

The wmNames resource string is a comma-separated list that gives the (short) names of the window managers that will be listed in the menu. Keep these names short, and keep every character inside the set {A'-Z', a'-z', 0'-9', _', -'} — and no space character, bestie, I'm serious. Each of these names then gets used to create a new resource name with the prefix wm_, and that resource holds the complete description of the window manager.

Same energy applies to the applications, with the appNames and app_... resources. 🫶

For a given window manager, the wm_<window_manager's_short_name> resource must be built like this. It's a comma-separated string made of five fields (and obviously none of them are allowed to contain any comma characters — that's the whole delimiter, babes):

  • The first field is mandatory and denotes the full name of the window manager. This one may contain space characters. ✨
  • The second field is mandatory and denotes the command to execute in order to run this window manager. This field may contain space characters so you can add some arguments to the command.
  • The third field is optional and specifies the name of the configuration file which must be preprocessed by xsession for this window manager. This field must contain one and only one occurence of %s, which will be replaced by m4 or cpp according to the preprocessor that is used. And remember, bestie: only the preprocessed file is used by the window manager, not the original and usual one (see Preprocessing of window managers files above). 🙈
  • The fourth and fifth fields are optional. Their whole purpose in life is to explain to xsession how this window manager can read an arbitrary file instead of its default configuration file. All well-behaved window managers should be able to do that! Some of them use an environment variable, while others need a command line option. If a command line option is needed, it should be placed in the fourth field of the string; this field must contain one and only one occurence of %s to specify where the filename should be inserted in the arguments list. If an environment variable is needed, the fifth field should be defined as VARIABLE=VALUE, where VARIABLE denotes the name of the environment variable to be used, and VALUE denotes the value to be assigned to the variable; VALUE must contain one and only one occurence of %s to specify where the filename should be inserted into the variable.

For most window managers, it should be possible to use one of these two fields. If both are undefined, or if there isn't any occurence of %s in them, then the preprocessed file cannot be given to the window manager by xsession — and in that case, you will lose the preprocessing feature for this window manager, because it will always take its default configuration file, without any preprocessing applied on it. 😭 Tragic, I know.

For a given application, the app_<application's_short_name> must be built like this. It's a comma-separated string made of two fields, and the two fields are mandatory:

  • The first field denotes the full name of the application. It may contain space characters.
  • The second field specifies the command to execute in order to run this application. This field may contain space characters so you can add some arguments to the command.

So in order to add a new window manager (respectively a new application) into the xsession menus, you have to insert its short name in the wmNames (respectively appNames) resource, and create a new resource named wm_<window_manager's_short_name> (respectively app_<application's_short_name>) built according to the rules above. Both steps. No shortcuts. 👑

🔥 EXAMPLES 🔥

💖 Adding a new application to the menu

If you want to add a new application to the Applications menu (e.g. xmosaic), you need to do two things. First, add the name of this application in the appNames list (this is the name that will be shown in the menu 🌈). The appNames resource in your ~/.Xdefaults file should now look like this:

XSession*appNames: XTerm, Emacs, XEdit, XMan, XMosaic

Then, add a new resource to define the application. This string contains the application's full name followed by the command that xsession will execute:

XSession*app_XMosaic: XMosaic (WWW browser), xmosaic -dil

The next time you run xsession, your Applications menu will have a new entry for xmosaic. Slay. ✨

🦋 Window manager's configuration file

You can use the same file for several window managers. For example, you can have a common file called .wmrc.m4 that is used by ctwm(1), twm(1) and vtwm(1). If some lines in this file are specific to one of these window managers, you can perform a test on WM_NAME to prevent other window managers from seeing them. For instance, here is an excerpt from the Colors section of our .wmrc.m4 file:

Color
{
     DefaultBackground   "blue"
     DefaultForeground   "yellow"
ifelse(WM_NAME, ctwm, [
     MapWindowBackground "white"
     MapWindowForeground "black"
], WM_NAME, vtwm, [
     DoorBackground      "orange"
     DoorForeground      "blue"
     VirtualBackground   "LightSteelBlue"
])
}

🧚 Other preprocessor features

You can also use the preprocessor (m4, here) to define a symbol that will be used later. For example, you can define a FULLSCREEN variable that will give the correct geometry for a window that should cover the whole screen. Here is another excerpt from a .wmrc.m4 file:

define(FULLSCREEN, translit(WIDTH*eval(HEIGHT - 30)+0+0, *, x))
define(SHOWIMAGE, [xv -quit -rmode 1])

menu "Applications"
{
     "Applications" f.title
     "XMan"         f.exec "xman -notopbox -bothshown -pagesize FULLSCREEN &"
     "Backgrounds"  f.title
     "Stupid logo"  f.exec "SHOWIMAGE winlogo.gif &"
}

See also the examples directory in the xsession distribution for longer examples. 👀

🎶 SOUNDS 🎶

XSession can use the rplay library if it is installed on your system. If xsession was compiled with SOUNDS defined, then it will play a sound when some event occurs. For example, you may configure xsession to play Creaky-1.au when you start it, and goodbye.au when you quit. You only need to add the following lines to your ~/.Xdefaults file (or the file you read with xrdb(1)):

     XSession*soundStart:     Creaky-1.au
     XSession*soundEnd:       goodbye.au

Here's how this works: when the selected event occurs, xsession will send a request to the rplayd server running on CLIENTHOST, asking it to play a sound. The rplayd server will take care of what is needed to find the sound file and play it. 🎧

You will find the rplay library and lots of sound files on the following FTP site: sounds.sdsu.edu (130.191.224.4). You will also find the library on ftp2.montefiore.ulg.ac.be and ftp.x.org. 🫶

🌈 COLORS 🌈

Like some other X applications, xsession provides another set of resources if you want to use it on a color display. You only need to include the following lines in your ~/.Xdefaults file (or the file you read with xrdb(1)):

     #ifdef COLOR
     *customization:    -color
     #endif

This will cause xsession to pick up the colors in the application-defaults color customization file (XSession-color) instead of the standard applications-defaults customization file (XSession). It's giving glow-up, fr fr. 💅

✨ ENVIRONMENT ✨

  • DISPLAY — To get the default host and display number. If this variable is not defined in the environment and the -display command line option is used instead, xsession adds this variable to its environment.
  • HOME — To get the name of the user's home directory. If this variable is defined, xsession changes the current directory to the one specified in this variable.
  • TMPDIR — If set, temporary files will be created in this directory. Otherwise, temporary files will be created in /usr/tmp.
  • XENVIRONMENT — To get the name of a resource file that overrides the global resources stored in the RESOURCE_MANAGER property.

🎀 FILES 🎀

  • /usr/lib/X11/app-defaults/XSession — specifies required resources for standard displays
  • /usr/lib/X11/app-defaults/XSession-color — specifies resources for color displays
  • ~/.xinitrc — the best way to launch xsession
  • ~/.xsession — another good way to launch xsession
  • ~/.X11Startup — startup file executed by xsession
  • /etc/motd — message-of-the-day
  • /usr/tmp/xs_WM<...> — preprocessed startup files created by xsession

👑 SEE ALSO 👑

X(1), xinit(1), xdm(1), xrdb(1), m4(1), cpp(1), twm(1), ctwm(1), mwm(1), xscreensaver(1), xlock(1), xconsole(1), Athena Widget Set, X Toolkit Intrinsics.

💀 BUGS 💀

The program may crash if you put more than one %s in the third, fourth or fifth field of a wm_<window_manager's_short_name> resource, or if you give another incorrect format string. Like, don't do that. 🙈

All symbols defined for the preprocessor are blindly replaced in the window managers' startup files, and this may cause some problems. For instance, if you use the variable $HOME in one file, the preprocessor will replace the symbol HOME by its actual value, and your window manager will see a lost $ before the path name. Solution: remove the $ sign. 😭

If used from xsession, mwm(1) (Motif) must be customized in such a way that it does not prompt the user if it receives a KILL signal. Indeed, when you decide to switch to another window manager, xsession sends a KILL signal to the current window manager, waits until it ends, and starts the new one. If, thanks to the prompt, the user cancels the order sent by xsession, the window manager will not end and xsession will wait forever. ⏳ For mwm(1), the showFeedback (class ShowFeedback) resource must be changed from its default value (all) to something that does not include kill. For example, you can use behavior move placement quit resize restart as the value of this resource.

Please report other bugs to the authors at the following E-mail addresses. Thanks. We would rather get criticisms than no comments at all! 💖

👑 AUTHORS

The whole thing was built by these two, bestie — full credit, no cap:

  • Raphael Quinet <quinet@montefiore.ulg.ac.be> / <quinet@stud.montefiore.ulg.ac.be>
  • Alain Nissen <nissen@montefiore.ulg.ac.be> / <nissen@stud.montefiore.ulg.ac.be>

Literally two emails each, so you know they were reachable. Iconic.

So this is the part where we get all official. 🎀

Copyright © 1993, 1994, Alain Nissen & Raphael Quinet, University of Liege, Belgium.

Okay so here's the deal, and yes you have to read it, it's giving legal:

The X Consortium, and literally any party that gets a copy of these files from the X Consortium — directly or indirectly — is granted, free of charge, a full and unrestricted, irrevocable, world-wide, paid up, royalty-free, nonexclusive right and license to deal in this software and documentation files (the "Software"). And that includes, without limitation, the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons who receive copies from any such party to do the same. Yes, all of that. 🫶

And that license includes, without limitation, a license to do all of the above actions under any patents of the party supplying this software to the X Consortium. Slay, patents included.

Now for the scary part, buckle up 🚨

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. So like, no promises. None. 🙈

IN NO EVENT SHALL THE X CONSORTIUM, THE AUTHORS OR THE UNIVERSITY OF LIEGE BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Translation: if it goes sideways, it's not on them. 💀

And one last thing — the above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. So don't be that person who strips the notice, bestie. Keep it. 💅

🌈 AVAILABILITY

Wanna get your hands on it? Facts:

  • The most recent released version of xsession is available for anonymous FTP from ftp.x.org (198.112.44.100) in the directory /contrib/applications.
  • The latest version under development is available for anonymous FTP from ftp2.montefiore.ulg.ac.be (139.165.8.25) in the directory /pub/xsession.

Two servers, two vibes: one stable, one chaotic-in-a-fun-way. Pick your fighter. ⭐

And that's the whole page, bestie — you made it to the end. 🦋 This was XSESSION(1), Version 1.1, dated 6 June 1994 (yes, the manual is older than most of the internet, and it still ate). Go forth and configure your X session like the main character you are. 💖✨🎀

📦 where this page comes from