Gratuitous Window Dressing, Part 2
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.
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:
Similarly, you can start your desktop system from the command line in the same way. For instance, I could start KDE with:
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.
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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- LiveCode Ltd.'s LiveCode
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide