User:Erbingha/X-Terminal

X-Windows is the network-independent graphical user interface for UNIX systems. Learn the basic concepts of establishing an X-window session, including authentication issues. What is a computer "windowing system"? Early computer systems interacted with users via a simple typewriter-like device. Later, we got video screens, which eliminated paper and allowed some ability to control where output would be displayed. But interaction was still character based. English-like commands were typed, and text output resulted. Modern computer systems usually contain a display with graphics capabilities and a pointer input device (mouse). Programs go beyond text-based input and output. They can draw lines or images on the screen and take actions according to the location pointed to by the "cursor" of the mouse. An early problem with making programs that could use the graphics output and pointer input of modern computers was the lack of standards for interacting with the different hardware devices from different manufacturers. A secondary problem was that, whereas these modern systems are multi-tasking, meaning several programs can run simultaneously, the system needed to arbitrate how the programs got access to the graphics display and input devices. The purpose of a windowing system is to provide a device-independent standardized input and output graphical environment accessible to multiple programs, customizable and controllable by the user. The windowing system provides a standardized library of subroutines for the programmer to use for getting input and displaying output. Manufacturers of different displays can modify the inner workings of these routines to access their hardware, but the interface to the user program remains the same. The windowing system allows the program to create one or more "windows" on the display. It automatically directs output designated for one window to appear in the appropriate place. It handles problems such as the display of overlapping windows, or the temporary hiding of windows by the user. It generally allows the user to re-size the window and notifies the program so it can respond. It keeps track of which window is the current one for input from either the keyboard or the mouse, and notifies the program appropriately. Generally, the windowing system has some provision for user customization. A preferences or initialization file lets the user control how the windows will look or operate, without having to do any re-programming. Some common computer windowing systems are: * "Classic" Macintosh Finder and now "Aqua" under MacOS X. * Microsoft Windows 98, Windows 2000, etc. for Intel-based PCs * X-window - for all types of computers The X-window system: definitions and concepts. The X-window graphical interface system was invented at Massachusetts Institute of Technology in the 1980s. Its purpose was to provide complete device and network independence. That is, it was designed so that it would be easy to port (transfer) to a new type of hardware, and so that programs running on one computer could use the display on another. This second feature is particularly useful, because it means that a less expensive display station on the desktop can be used to interact with programs running on much more expensive mainframe or server computers. X has become a de-facto windowing standard for UNIX and other multi-tasking workstations. Since 1994, X has been supported by the X Consortium, a manufacturer's association. Their charter is to distribute and improve the X system. The X source code is completely in the public-domain and may be freely copied and modified. The X Consortium encourages manufacturers to develop the low-level interface routines needed for their hardware and to donate those back to the master distribution source. Programmers around the world have developed programs that use the X system and donated those to the X distribution or otherwise made them freely available. Different computer vendors would often make their own "enhancements" and changes to the "look and feel" of the X-windows system. This made it difficult to port programs from one system to another. During the past few years, the UNIX vendors have standardized on the "Common Desktop Environment", or CDE, which provides the same programming interfaces and same look on all systems. CDE resembles the "look and feel" of the Microsoft Windows GUI. Linux systems typically use the "Gnome" or "KDE" interfaces to X. X uses a client-server model to achieve its device and network independence. A single program, called the "server", controls the "services" of the X system, both the actual graphics display hardware, keyboard, and mouse, and the "software" services such as fonts and colors. All input and output is actually routed through this program. This server program must run on the computer to which the display is directly attached. The programs that want to access the display are called "clients". These programs call the X library functions to do input and output and so are independent of the actual device hardware. They can run on any computer on the network, not just on the same computer as the display! One of the X library functions allows them to open a connection to a remote "server". One of the options to the "client" program controls which "server" it will use. A "window manager" function is needed. This function allows you to move or re-size windows on the screen, make one window overlap another, turn a window into an icon to temporarily hide it, etc. This function can be provided by the X server software that is controlling the hardware. But in most cases, it is simply another client program which can run either on the computer with the display or on any other machine on the network! Various window manager clients have been written, and you can choose the one that fits your style best. In the X-window system, a "display" is a set of hardware consisting of one or more output screens, a keyboard, and a pointing device (mouse). The pointing device is assumed to have at least 3 buttons. Sometimes keyboard combinations are used to "emulate" mouse buttons, for example, when running X server software on a Macintosh computer with only a one-button mouse. The "display" is controlled by a single X server process. A computer may have more than one display, each controlled by its own X server process, but this is rare in practice. Most workstations have a single display. Displays are numbered from 0 (zero). In X-windows, a "screen" is a graphics output screen. There can be more than one screen per display, numbered from 0 (zero). The standard UNIX workstation has a single attached display screen. X client programs running on that workstation reference this attached display server with the address: localhost:0.0 meaning that it is locally attached (the name "localhost"), display 0 (number following the colon) and screen 0 (number following the dot). Other synonyms for the locally attached display are "local", "unix", or no name at all (just specify the display as :0.0). An X client program can reference a display server on a remote computer by using the remote computer's host name or IP address in place of the term "unix". The remote name should include the domain name if it is not in the same domain as the client computer. X-window system usage and control. Server startup on UNIX workstations. On UNIX workstations, the X server and client programs are often run on the same local machine. On most UNIX workstations, the X server is always running and controlling the console display, including providing a fancy login dialog. On others, such as many Sun systems, you first log in on the console as a "dumb" terminal, and then start the X server by typing a command to start the X server. You need to consult the documentation for the workstation you are using to find out this command name. It could be simply "X", or "xinit, or "openwin" (on older Suns), or something else. On pangea, and many UNIX systems, a general overview of the X-window system can be found in the on-line manual entry for "X", that is, by typing the command: man X On pangea, this is a very long manual entry with information about starting X sessions, standard X client programs, access control, fonts, colors, keyboard mappings, common program options, setting program preferences, example commands to start client programs, and more. In any case, once logged in with X running, several default windows (client programs) are usually created for you, including a "console" terminal emulator window for system error messages (this is also the master shell for all your X clients) and a local "xterm" terminal emulator window for your normal command line login shell. The system manager can configure the default windows and may include a clock, load monitor, etc. Certain default "resources" such as fonts and colors are also set. You can customize for your own account the list of default windows (clients) that start automatically with the X server. You do this with a initialization shell script in your home directory, usually named ".xsession" or ".xinit". Consult the manual for the workstation you are using to find the exact name. This contains ordinary shell commands like the ".login" file that controls your login shell options, but applies only when you start the X server running on that particular workstation, or connect from an X terminal using XDMCP (see below). Usually, if this script is present, it completely controls which X programs are started for your session. That is, the system defaults only apply if this script is absent. You can also customize which software resources are made available automatically for your own account by the X server, such as background and foreground colors, scrolling behavior in terminal windows, etc., with a file in your home directory usually called ".Xdefaults" or ".XResources". The exact name to use will be referenced in the ".xsession" or equivalent initialization script. On modern UNIX systems that use the Common Desktop Environment, the simplest way to customize your X sessions is to use the menus available once you are logged in. Your settings are automatically stored in special initialization files in your home directory. Generally, the X environment on a UNIX workstation is set up so that if you kill the "console terminal emulator" (e.g., type "exit" in that window), you will kill your entire X session (kill all running X clients that are using the display). Or, you can sometimes kill the whole session from the window manager process. For example, in the CDE interface used on most modern UNIX systems, there is an "Exit" icon on the desktop; click on that to end your entire X session. Using an X terminal, PC or Macintosh as an X server. To use a PC or Macintosh as an X-windows display, you must run an X server program on that computer. Commercial programs that have worked well here in Earth Sciences are "Exceed" for Windows PCs and "eXodus" for Classic Macintosh (MacOS 8 or 9). Apple has integrated the X Window server as a downloadable option for MacOS X (version 10.2 or later). There is also an alternative XDarwin open-source port of X Windows for MacOS X (all versions). A dedicated X terminal is basically a specialized computer that runs only a single program - the X server. In this regard, it operates much like a PC with an X server program. Some groups in Earth Sciences use such X terminals (from Tektronix or NCD) because they require no active management. In its simplest form, such an X server program will start up on the PC or Macintosh without opening any windows (clients). This is because the clients normally run on another computer, not the PC or Macintosh, and you must first establish a connection to that other computer. You can use this type of X server or terminal in two different ways. First, you can create an X "session" on a remote (usually UNIX) computer that looks just like the desktop would on a graphics console attached to that remote system. This is done with the XDMCP protocol (see below). The remote computer is considered the "controlling computer" for this X display. In this case, the X server window manager takes over either the entire PC display, or a large portion within a single window. This is often called a "rooted" display. If you create an X "session" on your PC, then the normal X initialization files stored on the remote system (such as .xsession or .Xdefaults or the files created by CDE) will be run to customize the display to your preferences. In this "rooted" mode, you get the full use of the X-window manager features no matter which PC or X terminal you are using. On the other hand, this mode starts up many associated processes on the remote (UNIX) computer that you may not need for a specific task. Second, you can use some kind of "remote command" facility on the PC, Mac, or X terminal to start only specific X client programs on the remote (UNIX) computer. These X clients will open their individual windows on your PC display. The remote computer is not controlling your display. In this case, the windows from the X client programs are often intermingled on the PC display with windows from its native operating system, and controlled the same way as the native system. This is often called a "rootless" display. In the rootless mode, your display is not customized by the initialization files stored on the remote system, unless you specifically run commands on the remote system to do that. This mode is useful when you are using local programs on your PC and just want to get output from a single specific program on a remote (UNIX) system. For "rootless" operation, you can use a program on the PC or Mac such as "ssh", "telnet", "rsh", or "rexec" to start up the client X programs that you want on the remote (UNIX) computer. The safest and easiest way to run in rootless mode is to use an "ssh" client on your PC or Mac that supports X-window "tunneling". Ssh will encrypt your password and all your X-window traffic. It sets up a "fake" X display number on the remote computer to which your clients on that system direct their output. Then ssh tunnels that output back to the local PC or Mac. Ssh also takes care of the X-window access control issues automatically. If you don't have an ssh client for your PC or Mac that supports X-window tunneling, then connect to the remote computer with the most secure login method that you have, preferably Samson with PCLeland or MacLeland to campus UNIX computers, or ssh elsewhere, with plain telnet as the last resort. Once connected, run the "xterm" (terminal emulator window) program in the background, pointing back to your PC or Mac as the X display (see "starting clients", below). Once the command line window from the "xterm" program pops up on your PC display, you can then quit the Samson/ssh/telnet session and start any remaining X clients that you want from your xterm window. X server programs for PCs and Macintosh (such as "Exceed" and "eXodus") often include "remote command" facilities that use the "rexec" or "rsh" protocols to start X clients on the remote system. These allow you to customize a menu of commands on your PC that you can execute at any time to get an appropriate X client running on the remote system. Be aware that many server systems, such as pangea, accept connections to the "rexec", "rsh", and similar services only from the local network, for security reasons. If these "remote commands" don't work from your X server software, that is the likely reason. XDMCP protocol for remote X servers. There is a special protocol called XDMCP (an acronym for X Display Manager Control Protocol) that allows X servers, such as X terminals or PCs or Macintosh computers running X server software, to emulate a directly attached UNIX workstation console. The UNIX computer must be running the "xdm" process (or equivalent), and the X terminal must be configured to use XDMCP to make connections. In this case, you will get a standard graphical login screen for the remote UNIX computer, just as you would see if seated directly in front of the UNIX console. This connection method creates an X "session", and the remote UNIX computer becomes the controlling computer for your display. Your X terminal or PC/Mac X server software will usually provide two ways to make an XDMCP connection. First, it may allow you to simply type in the name of the remote computer on which you want to run your X session. Second, it usually provides an XDMCP "Chooser" window. For this "Chooser", your X terminal or PC sends out a broadcast message on the local network asking all computers running the xdm server to respond. It then constructs a list of the responding computers and lets you select a computer from the list. Some X server software programs will sort the list alphabetically; other programs just list systems in the order in which they responded. This "Chooser" function only shows remote computers on your own local network (for example, the Earth Sciences network consisting of Geology Corner, Mitchell Earth Sciences, and Green Earth Sciences buildings). After selecting the remote computer on which you want to run your X session, your X terminal or PC will contact that system and let it put up its normal graphical login display on your local display. You login with your normal account name and local password. NOTE: this login method passes your local password across the network in plain text, which makes it potentially vulnerable to capture by a hacker who has broken into your network. After starting your X session via XDMCP, your normal X initialization files stored in your home directory on the remote computer will be read and executed (such as .xsession and .Xdefaults files). Thus, the standard windowing clients, including the window manager, that you would see on the workstation will also start up and display on your remote X terminal or PC. XDMCP is the best way to configure a remote X terminal or PC when you want to run X client programs on the UNIX system that expect to have the full environment of the workstation console. XDMCP also provides access controls to prevent random X clients from displaying on your screen. Of course, your X terminal or Mac/PC X Server must support the access control protocols to make this work -- most modern ones support the access control protocols listed below. Starting clients. X clients are programs like any other UNIX program. That means that they have to be started either directly by another program (as from an initialization file or shell script), or by being typed in on the command line of a login shell, just like any other program. If you are logged into an X session, the X-window manager (such as CDE) may provide on-screen graphical menus that you can use to start "standard" X client programs. If starting X client programs from the command line of a login window (or xterm window), remember to start them in the background (that is, with the & symbol at the end of the command line). Each should run as a detached process, interacting through its own window. If you start an X client in the foreground, then your login shell will be tied up waiting until that one client exits. When you work on a UNIX workstation with integrated graphics display and X server, or when your remote server (X terminal or PC) connects to a UNIX system via the XDMCP protocol to start an X "session", your "standard" X clients are generally run on that same UNIX computer and started for you automatically (via the ".xsession" file, for example). One of those standard clients is usually an "xterm" window providing a login shell. However, X client programs can run on any computer on the network and be directed to communicate with the X server on any other computer. From your workstation display, you can remotely log into another UNIX computer and start an X client there pointing back to your workstation. The same thing is done (perhaps by "telnet" or a "remote command" facility) when your X server display is a PC or Macintosh. The key issue for running an X client on a remote computer is telling the X client how to get back to the "local" workstation (or PC or Mac) which is running the X server. All X clients accept a standard option for designating the X server to use, in the form: -display hostname:n.m Where "hostname" is the network hostname, qualified with domain name as needed (or use the IP address directly); "n" is the display number on that host (usually 0); and "m" is the screen number on that host (usually 0). For example, if I am logged into the console on the workstation "eluard" and want to run the "xload" client on pangea with the output window coming back to eluard, I could start this program on pangea with the option: xload -display eluard:0.0 If the "-display" option is not given to a client, then it will check to see if the environment variable named "DISPLAY" is set, and use that value. This variable is automatically set when you use the XDMCP protocol to connect a remote X server to a UNIX computer. The "xterm" client also always tries to set this DISPLAY variable, so one good way to run X clients on a remote machine when you do not want the full login environment provided by XDMCP is to first start an "xterm" client pointed back to your display with the "-display" option, and then start all other X clients from within that xterm login session. Finally, if the "-display" option is not given, and the DISPLAY variable is not set, then an X client will attempt to connect to the locally attached X display (localhost:0.0), if there is one, or fail otherwise. Authentication. Most X servers provide a way to keep "unwanted" client programs from opening windows on the display. You don't want other people to be able to randomly open windows on your workstation! In particular, you want to prevent hackers using other computers on the network from running a "spy" client that will access your display and secretly let the hacker see what you are typing, including any passwords you may type. Such spy programs have been distributed in the hacker community. X-terminals and X server software running on Macintosh or PC computers may have specific mechanisms for controlling access. Often, you can turn on an option that prompts you to authorize every X client program that is attempting to connect to your X server. If you get such a prompt when you don't expect it, say "No"! For X displays attached to UNIX workstations (that is, the workstation console display), or for remote X servers connecting via the XDMCP protocol, the most common methods of access control are either "host based", or "account based", using the MIT-MAGIC-COOKIE protocol. Finally, you can use an ssh X-window "tunnel" to make a secure connection between the computer with the X-window server program (your PC or Mac, for example), and the computer running the X client programs (pangea, for example). This tunnel encrypts all traffic and guarantees that only the client programs that you run can use the display. Host based access control For host based access control, you can permit all clients from a particular host, or none, to have access to your display while you are logged in. Unfortunately, this form of access control does not allow you to selectively list client programs or user accounts that can have access to the display. It either allows all users and programs from a specific computer to have access, or none. It is better to use the account based MIT-MAGIC-COOKIE form of access control, or an ssh tunnel, if those are available. But if host based access is the only available method, you should be sure to prohibit access from all computers except the ones where you are running X client programs. Often, host based control defaults to letting any program on any computer access your X window server. The X server stores the list of allowed hosts while it is running. Some window managers allow you to modify this list using a special menu item. Otherwise, the UNIX "xhost" command can modify the list when run from a computer that has control of the display. This would be the case if you were logged into the graphics console of a UNIX workstation, or if your X terminal has started an XDMCP session with the UNIX workstation. With no options or arguments, the xhost command shows you which computer hosts currently have access to the display. Plus (+) or minus (-) options, followed by a computer name, allow you to grant or deny access to specific computer hosts. With no computer name following, the plus and minus options apply to all computers on the network. Appropriate xhost commands can be included in your ".xsession" or equivalent X startup script. Examples: xhost - Prohibit access from any computer on the network, unless it is specifically given access via an xhost + command. You should first add the controlling computer (the one where you run the xhost command) to the list of allowed computers, for example, xhost +pangea. Then you can run xhost - to prohibit all other computers not in the "allowed" list from accessing the display. If you don't explicitly allow the controlling computer first, then even it will not be allowed access and you won't even be able to issue additional xhost commands. It is a good idea to run the sequence of xhost commands shown above in your startup script to set initial access to the controlling computer only. Then you can issue additional xhost commands to permit access to other hosts where you generally run X client programs. xhost + Turns off access controls. That is, X client programs on any computer on the network are allowed to access the local display. Never issue this command! This is an open invitation to hackers to try to spy on or disrupt your X sessions. Unfortunately, some X window server programs start up in this state, where they allow access by anyone. So you need to take positive steps to limit access. xhost +banach.stanford.edu Allow X client programs running on banach.stanford.edu to have access to your display. You might issue this command just before running an X client program on banach. xhost -nana.stanford.edu Explicitly prohibit client programs on nana.stanford.edu to have access to my display. You might run this command after you have started X clients from nana, in order to prevent further unauthorized clients on nana from accessing your display. The host based access method controlled by the xhost command either allows all users on a particular host to connect X client applications to your display, or none. On a multi-user system this leaves you open to pranks or deliberate interference by other users. For this reason, the account based control method described below is preferred. In a situation where the X server only supports host based access, one strategy for using it is to issue the appropriate xhost command, allowing access from a particular host only, just before you run the X client you want from that host, and then to deny access again. For example, if I am logged into an X session on the console of a workstation called fuego, and I want to display a "load monitor" for pangea on my display, I might use the following commands to temporarily grant access to my display from pangea X clients only long enough to run the needed xload command on pangea. xhost +pangea ssh pangea xload -display fuego:0 & xhost -pangea Account based access control via MIT-MAGIC-COOKIE An obvious improvement over host based access control would be to have a system that could recognize when an X client is started by you, regardless of which host it is running on, and only allow those clients to display on your X login session. The MIT-MAGIC-COOKIE protocol is an attempt to implement such a system. This protocol is supported by all modern built-in X servers on UNIX workstations. For remote X terminals and PCs/Macs running X server software, it depends upon cooperation between the X software program on the remote terminal or PC, and the UNIX process (usually "xdm") that implements the XDMCP protocol. Again, this should not be a problem for modern systems. When an X session is started via login on the UNIX console or via XDMCP, the X server generates a random string of bytes, called an "authorization record" or "cookie", which is stored in the file .Xauthority in the user's home directory. The permissions on this file are set so that only the user's account can read it. When X clients start, they automatically attempt to read the .Xauthority file and supply the information therein to the X server as their "cookie" to get access. Only X clients that you start will have access to the correct .Xauthority file to get the correct information to be allowed access to your X login session display. Of course, you would like your accounts on other computers to have access to that same .Xauthority file so they, too, can run X client programs that display in your X login session. This can be done transparently if your home directory is shared from a central server by a set of computers. Or, you can propagate that .Xauthority file yourself to your accounts on other computers. To do this, use the xauth command to extract the authorization record from the "home" machine to which your X server is connected; move that record to the remote machine (for example, with scp, or ftp; and then run xauth again on the remote machine to merge the authorization record into your .Xauthority file on that machine. See the online manual entry for xauth for an example of a single command that does all three steps in an rsh pipeline, and for details on command options. After you have copied the authorization record to the remote computer, you can run X clients from that computer to display on your current X login session. This MIT-MAGIC-COOKIE protocol is not foolproof. For example, in the case of a remote X server connected to a UNIX machine via XDMCP, someone with the ability to run a "sniffer" program on a computer attached to your local network may be able to capture the network packets between the host computer and your X display and decode the "cookie". He could then use it to run X client programs that access your display. This is an extremely unlikely scenario in a normal workplace environment, however. If an X server supports both the host based access control managed by the xhost command and the MIT-MAGIC-COOKIE account based authorization system, the less restrictive one may be applied by default. eXodus for the Macintosh is such a server. That is, the server may automatically add the current login host (or even "any host") to the list of allowed hosts for X clients, thus bypassing the account based authorization requirements. It is a good idea to run the xhost command to see what host based access is in effect. To force the account based access to be used, you may have to disallow all host based access, using the xhost - command described above. ssh X-window tunnels The "host based" and "magic cookie" access controls described above are built-in to the X-window protocol and are easy to use and fairly effective if your X display has a "controlling computer" and all your client programs will run on that computer. You will have a "controlling computer" if you login to the directly attached graphics console of that computer or if you start an XDMCP session from that computer to your X terminal. If you want to run client programs from multiple computers, or use an X terminal in a "rootless" mode where individual client programs can open windows, but there is no X "session" from a controlling computer, then the host based and magic cookie access methods either fail to work or are very cumbersome to use. In this case, there is a much better alternative: use the ssh program with an X-window tunnel. This is not a part of the X-window protocol, but has been designed to work with it. Normally, X client programs on each remote computer make a direct connection to your display, and thus have to be listed in the host access list or supply the correct magic cookie to work. Ssh X tunnels trick the client programs into thinking that they are displaying directly on an attached console, where they always have permission to run, even under the most restrictive settings, and trick the X display into thinking that the client program is running locally and has the proper magic cookie. Then ssh makes a network tunnel to transfer the actual X-window commands and data between the client computer and X display server. Because you must supply your password on each remote computer to start up the tunnel with ssh, and because your password and all the X-window commands and data are encrypted before they are sent on the network, ssh tunnels provide a very high level of security and privacy. Window operations. Window operations such as moving and resizing windows, bringing one to the foreground, etc., are not usually built in to the X server, but instead are controlled by a "window manager" program that you must run. This program is an X client like any other and does not have to run on the same computer as the X server. Only one window manager program should ever be connected to a particular X server. Imagine the chaos if two different window manager programs are trying to manage the same display! On UNIX workstations, or X terminals connecting via XDMCP, a window manager is usually started for you automatically in the ".xsession" or equivalent startup file. The major UNIX vendors are now standardizing on the "CDE" window manager to give a consistent "look and feel" that resembles Microsoft Windows. For an X terminal or PC or Mac X server that is not connecting via XDMCP (running in "rootless" mode), there may be a built-in window manager, or you may want to start one on the remote UNIX system. Use a remote command procedure, such as ssh or telnet, to access the remote UNIX system and start the window manager just as if it were another X client program. Two "standalone" window managers that are usually available on UNIX systems are "mwm", which provides most of the functionality of the CDE window manager, and "twm", which is a very simple window manager. Check their on-line manual entries for operational instructions. Which window is active? Generally, all X clients can write output to their windows simultaneously. Data can be updated in all windows at once. Only one X client can be receiving input at a time, however, because there is only one keyboard and mouse. This is called the "active" window, or the window with "input focus". For the CDE window manager (or mwm or the older DECwindows manager), you must click the mouse with the cursor somewhere in a window to make it active. In many PC or Mac X server built-in window managers, such as eXodus, you also must click the mouse after moving its pointer to a window in order to make that window active. This is to make these programs compatible with standard PC or Mac windowing operation. For the UNIX twm window manager, the active window is the one where the mouse pointer is found. You do not need to "click" on the mouse in that window to make it active - just move the pointer there. If the mouse pointer is not in any program window - but rather over some part of the screen background, which is called the "root" window, then holding down mouse buttons will generally bring up menus of window manager actions which allow you to do things like start or kill X clients, resize windows, etc. The standard X mouse has three buttons, but unfortunately, there is no standard for what the buttons do! You must check the documentation for a specific window manager or X client to be sure. Generally, basic operations where a mouse click is needed, such as selecting an item from a menu, use the left button. For a PC or Macintosh with a single button mouse, certain keys on the keyboard are generally taken over to provide the functions of the missing mouse buttons. Some clients have their own menus, or respond to certain keys (such as q), or even have a command line (such as an xterm) which provide a method to kill or exit the client. The window manager usually provides a function that allows you to kill any X client. For a PC or Mac, this may be a standard "close box". Finally, on UNIX workstations, or remote servers connecting via XDMCP, if you exit the master "console" window, it usually kills all your X clients and exits the entire X environment back to a login prompt for the next user. Similarly, on a PC or Mac with an X server, if you exit the X server program, it will generally kill all the clients that are connected to it. However, I have noticed cases on pangea where an X client that was started on pangea and pointed to a remote display did not die when the user logged off the remote system. It is best to explicitly kill all clients that have open windows on your display before logging off (or turning off) the display.