What is X Windows? X Windows is a "network transparent, platform independent" windowing system. What does that mean? It means basically that you have a system which allows you to have various programs on your screen, some of which may not actually be running on your local machine. You can run programs on remote machines and have them show up or display on your local (or other) screen. How does it work? That's a very deep question. A better question might be, "How much do I need to know to get X to work for me?" and even then, the answer can be rather vague. X Windows and getting it to work depends, as most things in the Unix world, on what you want and how you want it. Perhaps another question might even be "Does it work?" The answer to that last one is that it works well enough. X Windows is one example of a server-client system, with a twist of sorts. In most such systems, the server is some faraway machine and the client machine that accesses the resources on the server. In X, the server is on the local machine - or "display" to be more exact - and the client can be anywhere, accessing the resources that the server has to offer. Also, the clients and server tend to be on the same machine, while in some other examples, like NFS, the server and clients are typically on different machines. Some basic commands or clients: There are some X programs or clients that just about anyone can find a use for. xterm - terminal emulator for X xclock - analog / digital clock for X oclock - round X clock twm - tab window manager ctwm - (color) Tab Window Manager emacs - the emacs editor we know and love has X support xemacs - another emacs that is reliant on X netscape - the html browser known as mozilla xv - X11 image viewer xbiff - X11 mail notification xset - set (some) X11 user preferences xsetroot - Do stuff to the root window (the background) There are other clients too and some of those will come up later on. Window Managers There are a bunch of windows on your screen; how do you move them, get rid of them, control them? That is the role of the window manager. It puts stuff like borders and title bars on windows, gives you menus, and all in all make the whole affair prettier. The standard X11 window manager is twm. It is simple, elegant, small, and relatively fast. It has a configuration file called .twmrc, which is normally located in your home directory. Here is a list of more window managers: twm - tab window manager ctwm - color tab window manager with virtual workspaces fvwm - another virtual workspace type thats different tvtwm - another one that looks more like twm by default olvwm - another one that is based on Sun's OpenLook mwm - another one based on the Motif tool kit The window manager determines to a great extent what your setup will look like and how it will behave. I can't get into how to set up your window manager to do what you want, as only you know what you want, but a sample config file for ctwm, a .ctwmrc , is available via ftp as well as some associated files. Displays One concept in X Windows that deserves some explanation is the "display". A display is a "collection of monitors that share a common keyboard and pointer (mouse, tablet, etc.)." A machine typically only has one display but can, in the case of large systems, have more. This is, however, rarely seen in most computing environments. It is very common is to see one display with multiple monitors, or screens. Displays are referred to by names like the following: |----- screen number optional if its zero meeko.EECS.Berkeley.EDU:0.0 ^hostname |_______ display number The hostname part is also optional especially when referring to the local display, but having the full hostname there makes things easier in the long run. One thing you can do with the display is cause X client to use another machine's display. Lets say you are logged in on one of the workstations in the downstair labs and you want to run some X program that is only available on the big server machines, like parker.EECS. First you need to tell the X client that you want it to use the proper display. To do that you can either set the DISPLAY environment variable or use the -display flag rohan.cs % remsh parker.EECS.Berkeley.EDU passwd: parker.EECS % setenv DISPLAY rohan.CS.Berkeley.EDU; maker (you could also type maker -display rohan.CS.Berkeley.EDU) Xlib: connection to "rohan.CS.Berkeley.EDU:0.0" refused by server Xlib: Client is not authorized to connect to Server xterm Xt error: Can't open display: rohan.CS.Berkeley.EDU:0 What happened? Well you set the DISPLAY environment variable correctly. But yoy need to give the remote client access to your DISPLAY. There are two ways to do that; one is with the xhost command, and the other is with the xauth command. X Display Access As noted, there are two ways to give an X client access to your display. The first, xhost, is generally considered to be a "bad thing". The xhost command can be used to grant access to a display on a per host basis. So if you use the following command: jon@coke.CSUA % xhost +soda.CSUA.Berkeley.EDU soda.CSUA.Berkeley.EDU being added to access control list You would give access to every X client from soda.CSUA that tried to connect to your display on coke.CSUA, without regard for who it is on soda.CSUA might be running that X client. If you trust everyone on soda.CSUA not to do "mean things" then this might be alright for you. Most people dont however. But xhost does have good uses, for instance to restrict access to your display: jon@coke.CSUA % xhost - coke.CSUA.Berkeley.EDU - localhost coke.CSUA.Berkeley.EDU being removed from access control list localhost being removed from access control list Some people often do this so that people don't log into coke.CSUA from a remote machine and run X clients on coke's display or try to do it by setting their DISPLAY to localhost:0. A better solution is xauth. Xauth is used to pass around "magic cookies" around that a client must present to use a display. An example: jon@coke.CSUA % <that "xhost -" stuff> jon@coke.CSUA % xauth Using authority file /accounts/jon/.Xauthority xauth> list coke.CSUA.Berkeley.EDU:0 MIT-MAGIC-COOKIE-1 2ea6ab402d4a0dfa2029b72d0c6083c9 coke/unix:0 MIT-MAGIC-COOKIE-1 2ea6ab402d4a0dfa2029b72d0c6083c9 ... (more keys) jon@coke.CSUA % rsh parker.eecs -l csua-lib passwd: parker % setenv DISPLAY coke.CSUA.Berkeley.EDU:0 parker % xauth add coke.CSUA.Berkeley.EDU:0 MIT-MAGIC-COOKIE-1 2ea6ab402d4a0dfa2029b72d0c6083c parker % maker [then Framemaker appears on coke's Display!] So long as you are the only one who has access to that magic cookie, no one but you can access your display, barring bugs in the code for the Xserver. But there are mean nasty people out there who are also very hard working mean nasty people who manage to do things like run "packet sniffers" which can catch your passwds, "magic cookies", secret love mail, the like as they passed over the network. There is a solution, well several solutions. The one that is easiest to use - both for users *and* administrators is ssh, Secure SHell. Start up Files Now that you have all this stuff you want, you probably don't want to have to type all those commands everytime you login. Isn't there some start up file that will do this all for me like .login and .cshrc? Yup. The name of this file depends on how you start up X Windows. The two common ways are with xdm and commands like xinit or startx. X Display Manager -- XDM You are using xdm if you get a nice "pretty" login box on the screen. With xdm, the configuration file of note is called .xsession. It is an executable shell script (well if you are hardcore, you could make it a compiled binary, but that is just too problematic for most people). Here is a sample .xsession: jon@coke.CSUA % ls -l .xsession -rwxr-xr-x 1 jon member 510 Mar 3 1997 .xinitrc* jon@coke.CSUA % cat .xsession #!/bin/csh setenv CONSOLE no xhost - localhost xhost - `hostname` xset fp+ $HOME/lib/X11/fonts ctwm & xpmroot ~/lib/graphics/xpm/background8.xpm & xterm -rv -sb -n Here -geometry 80x24+0+0 & xterm -rv -sb -n There -geometry 80x24-0+0 & xterm -rv -sb -n Somewhere -geometry 80x24+0+349 & xterm -rv -sb -n Nowhere -geometry 80x24-0+349 & setenv CONSOLE yes exec xterm -n Everywhere -C -geometry 80x6+0-0 This is written in the C Shell, though it could just as easily be written in the Bourne shell, /bin/sh or any other shell. (well actually, on many Sun Solaris machines, the way X windows is installed and how the engineers wrote some of the scripts that are run when a person starts up a X windows session, you are forced to have a .xsession written in /bin/sh but you can get around that. You can take a look at an example of one way to do it.) Note that some commands are run in the background and some are not. The one that are not, like the xset and the xhost, are commands that will eventually exit and let the .xsession move on to the next command. However, the xterm's are commands that you don't want to exit immediately - you want them to hang around a bit. So you put them in the background with the "&" so that the .xsession can move on to the next command. The last command is called with "exec" so that when that command exits (say you type "exit" in the shell running that xterm) the whole X windows session will exit. Some people like to have a xterm for a "controlling" process, others like to exec a window manager or even a home grown program that "does what I want". Some common problems with .xsessions: * The .xsession file is not executeable: o Symptoms: You login and then the screen resets and get a login box again. o Solution: chmod +x ~/.xsession (In /bin/sh: chmod +x $HOME/.xsession) * All of your commands are run in the background with "&" o Symptoms: You see a flurry of client display and then they all exit mysteriously. o Solution: Make sure that last client is not executed in the background. Xinit and .xinitrc If you login on a "plain-text" console which has no graphical login box, then whoever set up your machine expects you to use a command like this: seltzer% xinit or seltzer% exec xinit [Hey, what's the difference?] or seltzer% openwin or seltzer% startx This way of starting up X Windows works well if there are other windowing systems installed on the machine besides X or if you'd prefer not to run X all the time as one would have to with xdm. In some ways, starting X in thie manner is much easier and is more likely to do "what you want". When starting up X in this manner, you have a configuration file simiar to the .xsession called .xinitrc. Unlike a .xsession, your .xinitrc does not have to be executeable, though sometimes users will make a link (with ln or ln -s) from one to other. It does need to be written in some valid shell language. EECS Instructional tips The Unix machines run by EECS Instructional run something called CDE which is based on X Windows but adds a lot onto it. The biggest question people have about it is "How do I get rid of it and run regular X Windows?" To do that you need to write a file in your home directory called .dtprofile with a line like this: hepburn.cs% cat .dtprofile SESSIONTYPE=xdm Fun Stuff There are a number of things you can do to make your X setup fun or at least amusing while you're working late at night on your project and need some cheap laughs. xdaliclock xeyes xsnow xoj, xant, xroach, xbaby, xphoon various games (banned by EECS Inst on their machines)