Is a "Display Manager" the same thing as a "Session Manager"?
Answer: No they are not the same. The session managermanages your session, and the display manager is responsible for providing you with a login interface.
Likewise, is a "Windowing system" the same thing as a "Window manager"?
Answer: No they are different. The window mangager sits on top of the Window system.
The Window system: Each currently running application is assigned a usually resizeable and usually rectangular shaped surface of the display to present its graphical user interface to the user; these windows may overlap each other, as opposed to a tiling interface where they are not allowed to overlap.
The window manager: When a window manager is running, some kinds of interaction between the X server and its clients are redirected through the window manager. In particular, whenever an attempt to show a new window is made, this request is redirected to the window manager, which decides the initial position of the window
Session Manager
source
In the X Window System, an X session manager is a session management program, a program that can save
and restore the current state of a set of running applications.
X window manager
source
An X window manager is a window manager which runs on top of the X Window System, a windowing system
mainly used on Unix-like systems.
Types of window managers
- Stacking window managers
- Tiling window managers
- Compositing window managers
- Virtual window managers
- Window managers that are extensible
The user can choose between various third-party window managers, which differ from one another in several ways, including:
customizability of appearance and functionality:
textual menus used to start programs and/or change options
docks and other graphical ways to start programs
multiple desktops and virtual desktops (desktops larger than the
physical monitor size), and pagers1 to switch between them
consumption of memory and other system resources
degree of integration with a desktop environment, which provides a
more complete interface to the operating system, and provides a range
of integrated utilities and applications.
While the main aim of a window manager is to manage the windows, many window managers have additional features such as handling mouse clicks in the root window, presenting panes and other visual elements, handling some keystrokes (e.g., Alt-F4 may close a window), deciding which application to run at start-up, etc.
Display manager
source
(there is a list of display managers in the source website)
A display manager, or login manager, is typically a graphical user interface that is displayed at
the end of the boot process in place of the default shell. There are various implementations of
display managers, just as there are various types of window managers and desktop environments.
There is usually a certain amount of customization and themeability available with each one.
X display manager
source
In the X Window System, an X display manager runs as a program that allows the starting of a session
on an X server from the same or another computer.
A display manager presents the user with a login screen which prompts for a username and password.
A session starts when the user successfully enters a valid combination of username and password.
The X window system
source
Debian manual for x window system
xorg site
The X Window System (X11, X, and sometimes informally X-Windows) is a windowing system for bitmap displays, common on UNIX-like computer operating systems.
X provides the basic framework for a GUI environment: drawing and moving windows on the display
device and interacting with a mouse and keyboard. X does not mandate the user interface — this is handled by individual programs. As such, the visual styling of X-based environments varies greatly;
different programs may present radically different interfaces.
In lots of places, depending
On virtual terminals and real terminals, the TERM environment variable is set by the program that chains to login, and is inherited all of the way along to the interactive shell that executes once one has logged on. Where, precisely, this happens varies from system to system, and according to the kind of terminal.
real terminals
Real, serial, terminals can vary in type, according to what's at the other end of the wire. So conventionally the getty program is invoked with an argument that specifies the terminal type, or is passed the TERM program from a service manager's service configuration data.
systemd's variability
The serial-getty@.service service unit file, or drop-in files that apply thereto, is where to change the terminal type for real terminals on systemd systems. Note that such a change applies to all terminal login services that employ this service unit template. (To change it for only individual terminals, one has to manually instantiate the template, or add drop-ins that only apply to instantiations.)
systemd has had at least four mechanisms during its lifetime for picking up the value of the TERM environment variable. At the time of first writing this answer, as can be seen, there was an Environment=TERM=something line in the template service unit files. At other times, the types linux and vt102 were hard-wired into the getty and serial-getty service unit files respectively. More recently, the environment variable has been inherited from process #1, which has set it in various ways.
As of 2020, the way that systemd decides what terminal type to specify in a service's TERM environment variable is quite complex, and not documented at all. The way to change it remains a drop-in configuration file with Environment=TERM=something. But where the default value originates from is quite variable. Subject to some fairly complex to explain rules that involve the TTYPath= settings of individual service units, it can be one of three values: a hardwired linux, a hardwired vt220 (no longer vt102), or the value of the TERM environment variable that process #1 inherited, usually from the kernel/bootstrap loader.
(Ironically, the getttyent() mechanism still exists in the GNU C library, and systemd could have re-used the /etc/ttys mechanism.)
kernel virtual terminals
Kernel virtual terminals, as you have noted, have a fixed type. Unlike NetBSD, which can vary the kernel virtual terminal type on the fly, Linux and the other BSDs have a single fixed terminal type implemented in the kernel's built-in terminal emulation program. On Linux, that type matches linux from the terminfo database. (FreeBSD's kernel terminal emulation since version 9 has been teken. Prior to version 9 it was cons25 OpenBSD's is pccon.)
- On systems using
mingetty or vc-get-tty (from the nosh package) the program "knows" that it can only be talking to a virtual terminal, and they hardwire the "known" virtual terminal types appropriate to the operating system that the program was compiled for.
- On systemd systems, one used to be able to see this in the
/usr/lib/systemd/system/getty@.service unit file (/lib/systemd/system/getty@.service on un-merged systems), which read Environment=TERM=linux
setting the TERM variable in the environment passed to agetty.
For kernel virtual terminals, one does not change the terminal type. The terminal emulator program in the kernel doesn't change, after all. It is incorrect to change the type. In particular, this will screw up cursor/editing key CSI sequence recognition. The linux CSI sequences sent by the Linux kernel terminal emulator are different to the xterm or vt100 CSI sequences sent by GUI terminal emulator programs in DEC VT mode. (In fact, they are highly idiosyncratic and non-standard, and different both to all real terminals that I know of, and to pretty much all other software terminal emulators apart from the one built into Linux.)
GUI terminal emulators
Your GUI terminal emulator is one of many programs, from the SSH dæmon to screen, that uses pseudo-terminals. What the terminal type is depends from what terminal emulator program is running on the master side of the pseudo-terminal, and how it is configured. Most GUI terminal emulators will start the program on the slave side with a TERM variable whose value matches their terminal emulation on the master side. Programs like the SSH server will attempt to "pass through" the terminal type that is on the client end of the connection. Usually there is some menu or configuration option to choose amongst terminal emulations.
The gripping hand
The right way to detect colour capability is not to hardwire a list of terminal types in your script. There are an awful lot of terminal types that support colour.
The right way is to look at what termcap/terminfo says about your terminal type.
colour=0
if tput Co > /dev/null 2>&1
then
test "`tput Co`" -gt 2 && colour=1
elif tput colors > /dev/null 2>&1
then
test "`tput colors`" -gt 2 && colour=1
fi
Further reading
- Jonathan de Boyne Pollard (2018).
TERM. nosh Guide. Softwares.
Best Answer
You can check the
$DISPLAYvariable to see whether you're on an x display - if it's non-empty, you have a display:A quick test showed this even works for X-tunneling.