Gratuitous Window Dressing, Part 2

Hello, everyone, and welcome back to the sunniest corner on Linux street, the "SysAdmin's Corner", where all find pleasure in the exploration of their Linux system. That means you. Last time around, we decided to visit one of the more controversial areas of the Linux experience, the desktop. Love 'em or hate 'em, desktops and window managers are integral parts of the Linux experience (and a necess

The command line rules!

There. I feel much better. On to today's column.

If you have run the X Window System in any way shape or form, you'll have accumulated a number of interesting files in your home directory. They have names like ".Xclients", ".Xauthority", and ".xinitrc" to name a few. What are these mysterious (dare I say it again) ".X" files? Well, before I go into that, let's start by looking at the program that invariably makes use of these files, a little something called xinit.

xinit is the master program for starting your graphical desktop. Using various ".X" files, xinit will create, build and otherwise start up your X session. But wait? Isn't that the idea behind startx? Well, in a sense, yes...and no. You see, the problem with using xinit to start your X session is that it is so darn complicated (or at the very least, wordy).

startx is actually just a Bourne shell front end to xinit. In fact, if you take a look through the file more /path_to/startx, you'll find that after setting a number of variable, paths and so on, xinit is finally called to start X. That path, by the way, is pretty much always one of the following.

     /usr/X11R6/bin
     /usr/bin/X11

Remember that really boring X terminal that I had you start in the first article of this series? What you did was create an empty ".xinitrc" file with nothing but a single line that read "xterm" in it. Then, I had you type startx to bring up the X Window System. What you wound up with was a plain X terminal that you could not move, resize or modify in any way. About the only interesting thing that I can think of doing in that environment is to type something like wmaker to bring up a desktop manager so you can actually do work. But that's a pretty weird way of doing things, and I digress.

You could have used the xinit command to start that xterm as well. From a console screen, you would type this command:

     xinit /usr/X11R6/bin/xterm

Similarly, you can start your desktop system from the command line in the same way. For instance, I could start KDE with:

     xinit /usr/bin/startkde

Here is what happens when you type startx. The shell script checks for the existence of a local ".xinitrc" file. In its absence, it then looks for the system wide version. This is called simply "xinitrc" (no dot at the beginning) and is usually found at /etc/X11/xinit/xinitrc. Your personal xinitrc file, the one that begins with a dot, can be quite simple, as in the case of the one line that said "exec xterm". The system-wide version is a bit more complex and checks for the existence of other .X files to pull into your configuration. For those of you running Red Hat, things are a tiny bit different. Your system-wide xinitrc file checks for the existence of something called "Xclients" or, its local version, ".Xclients".

In a sense, .xinitrc and .Xclients serve pretty much the same purpose. On a Red Hat system, you'll notice that in the absence of a local .Xclients file, it looks to the Xclients file (sitting at /etc/X11/xinit/Xclients). If you don't have an .Xclients file, Red Hat starts GNOME by default. That's a global setting. You can alter this behaviour (particularly if you have several users logging in to one workstation) by modifying the global Xclients file. Look for the line near the top of /etc/X11/xinit/Xclients that says "PREFERRED=". That variable is set to null right now. Change it to whatever you would prefer as the default desktop. If you wanted KDE, then that line would read as follows.

     PREFERRED=startkde

For the GNOME crowd, replace starkde with gnome-session. You rebels out there running ICE or WindowMaker...we'll get to you soon enough...in a follow-up article. Before I move on to something else, I want to mention one other X file. This one is ".wm_style" and, if you follow your global Xclients file, you'll see that it looks to something called .wm_style. This is the local user preference window manager. Just to make things extremely complicated, this is another alternative to .Xclients that allows for some free form expression. The global Xclients file looks for several variations of the window manager names. For instance, if you wanted to run WindowMaker, you could type WindowMaker, Windowmaker, WMaker or wmaker. Scan through the /etc/X11/xinit/Xclients file and you'll find the valid choices.

So, what other .X files do we have? .xserverrc defines the X server that you wish to run and is almost never used. The reason for this is that, by default, you run one and only one X server, whether it be your SVGA server, accelerated S3 server or a straight frame buffer server -- namely the one that works for your specific video card. If you don't set anything here, the system will run whatever /etc/X11/X is linked to. For instance, on the system I am using to write this article, X is linked to /usr/X11R6/bin/XF86_Mach64.

For the most part, people don't generally muck about with their X configurations once things work (more or less) pretty well -- unless, of course, they are the type of people who hang out on this corner. Nevertheless, those little .x_something or .X_something files that reside in your home directory do give you some amount of control as to just how your X environment behaves. Additionally, the .xinitrc file we talked about last week lets you make other changes even after you have finished configuring the X server with xf86config (or through the graphical install process). For example, one of the great annoyances that people run into is the misconfigured backspace key. You know...you wind up never backspacing because it adds some strange character you just can't shake.

Here's how you solve this annoyance. The easy fix is to define a new key with xmodmap, a utility designed specifically to remap keys for use under X. Let's pretend that you have a terminal session open and that your backspace key does not work. (If something is set up wrong, this is often the case.) Type the following:

     xmodmap -e 'keycode 22=BackSpace'

You can also use the command to modify the behavior of your mouse. Let's say that you have a 3 button right-handed mouse, but you are left-handed. It would be really nice if you could reverse the order of the buttons. No problem. Try this.

     xmodmap -e 'pointer = 3 2 1'

Suddenly, all of us right-handed people get to feel what it's like for our left-handed friends in a primarily right-handed world. If you want to put it back to what it was, change the sequence "3 2 1" back to "1 2 3", and everything will be as it was. Of course, this is not what we want to do each and every time we restart X. To make the changes permanent, add the command to your .xinitrc file just before the exec window_manager command (as discussed earlier).

We'll look at other ".X" files next time around and answer the question "what do you do when one desktop isn't enough?" We'll also start looking at different window managers and desktops and talk about their impact on the way you work and your system's limited resources. Then, I'll tell you how to override those nice defaults to make your system look like your system and yours alone.

Well, that should be enough to keep us all busy until next time. Take care everyone, and remember that a little gratuitous window dressing never hurt anyone. X needs no warning labels.

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix