Basic fvwm Configuration
This article is primarily intended for, and dedicated to, all the novices and newcomers who have joined the worldwide community of Linux users. Welcome aboard! This article will attempt to introduce you to one of the most versatile and popular X-Windows managers: fvwm (which, I've been told, originally stood for “Frugal Virtual Window Manager”). Its well-deserved popularity is based, among other things, on its relatively parsimonious memory consumption, an extensively customizable 3 Motif-ish appearance, a virtual desktop, and the ability to extend functionality through the use of modules.
Before we begin, let me state a couple of presuppositions:
1. You've installed X-Windows and the fvwm window manager and have them working, and
2. You're willing to tinker a bit.
If this is you, keep reading!
First, some background: the concept of a window manager is, in essence, a rather simple one. X-Windows itself oversees certain rudimentary tasks such as managing the display hardware (monitor, keyboard, and mouse), handling mouse and keyboard events, and creating the windows which appear on the display. Just exactly how windows appear and behave is left up to the window manager. Window managers, such as fvwm, control how you interact with programs by providing decorative window frames, window controls, menus, virtual desktops, and so forth. Change to a different window manager and you can create a completely different look and feel even though the programs which run under them are identical.
fvwm was developed by Robert Nation as a derivative of one of the original MIT window managers, twm (the Tabbed Window Manager, which started life as Tom's Window Manager in honor of its author, Tom LaStrange). fvwm is currently maintained by Chuck Hines. The latest official release is fvwm-1.24r, although a beta version—pre2.0pl40 (as of mid-December 1995)--is currently available as well. These can be found at: ftp://sunsite.unc.edu/pub/Linux/X11/window-managers/ ftp://ftp.hpc.uh.edu/pub/fvwm/ ftp://ftp.x.org/contrib/
In addition, there are a number of excellent WWW pages dedicated to fvwm which provide a wealth of information, screen shots, and sample .fvwmrc configuration files. These include:
T.J. Kelly's The fvwm Home Page: www.cs.hmc.edu/~tkelly/docs/proj/fvwm.html
Todd Postma's fvwm Info: http://xenon.chem.uidaho.edu/~fvwm/
Jens Frank's fvwm Documentation: namu19.gwdg.de/fvwm/fvwm.html
Erik Kahler's fvwm Home Page: mars.superlink.net/user/ekahler/fvwm.html
At this point it's probably worth mentioning that if you're serious about customizing fvwm, it's a good idea to get the sources even if you don't intend to compile your own version. Why? Some Linux distributions do not include full documentation for every program. Getting the sources for fvwm ensures that you'll have the complete documentation, including manual pages for the various fvwm modules. Also, if you do choose to compile fvwm yourself, you can determine which features you wish to include.
Some of the basics we'll try to cover include:
1. Managing configuration files
2. Starting programs at load up
3. Adding items to the fvwm popup menus
4. Color customization
Keep in mind that the information presented here is intended to be used as a primer. I'd recommend skimming through the manual pages for fvwm in addition to reading this article. The definitive source of information is the manual page and documentation that comes with the program source distribution.
The first thing that you'll need to know about fvwm is where the configuration file is found. When fvwm starts, it first looks for .fvwmrc in your home directory. For example, if your username is johndoe, fvwm looks for the file /home/johndoe/.fvwmrc. If this file is absent it then looks for the system-wide configuration file /usr/lib/X11/fvwm/system.fvwmrc. If neither of these files are present, it simply exits.
One of the first things you'll want to do is make a copy of the default system-wide configuration file and put it in your home directory:
$ cp /usr/lib/X11/fvwm/system.fvwmrc ~/.fvwmrc
Be sure to copy this to ~/.fvwmrc and not ~/system.fvwmrc. Creating a copy of the file in your home directory is a good idea for a couple reasons:
1. If your .fvwmrc file gets corrupted, fvwm will fall back to using the system-wide configuration file.
2. If ~/.fvwmrc inadvertently gets deleted, you can use the system.fvwmrc file to re-create it.
3. On a multi-user system, it allows each user to customize her/his own .fvwmrc file.
The other issue to think about at the outset is sequential customizations. Chances are, over the course of several weeks or months, you'll make numerous small and large changes to the config file as you get fvwm customized to work the way you want it. What happens when you accidently overwrite or delete system.fvwmrc or your .fvwmrc? Serious bummer.
Managing system configuration files is important for anyone who is running, and likely administering, his own Linux system. It is wise to have a well-thought-out plan for how changes are implemented and changes tracked. Never do what you cannot undo. fvwm uses a single configuration file, making this a fairly simple task. Here are a few suggestions.
Before making any changes in a default configuration file, make a backup of it and give it a distinctive suffix, such as .dist. For example, before you edit the system.fvwmrc file for the first time, you'd make a copy of it by:
# cp system.fvwmrc system.fvwmrc.dist
The .dist suffix alerts you to the fact that this is an original file from the distribution. To further safeguard it, you should copy this to a directory owned by root (the superuser) and set the permissions on that directory to read and execute only, except for root. To do this, you could, for example, make a directory in your /etc or /usr/local directory called backups/ and then copy all default config files to this directory.
To do this, log in as root and enter:
# mkdir /etc/backups # chmod 755 /etc/backups
Setting the directory permissions, as root, to 755 allows root full read, write, and execute permissions, while preventing write permissions for everyone else. With read and execute permissions, users may change to the directory and do a file listing but cannot (since they don't have write permission to that directory) delete a file.
After you've created a backup directory and set the appropriate permissions you should, as root, make backup copies of important configuration files with the .dist suffix. You can also set the permissions for each file to read-only by:
# chmod 744 /etc/backups/system.fvwmrc.dist
This limits permissions on the file to read only for all users except root. Making backups of default configuration files is helpful only if it actually works. Obviously, you'll want to make a backup copy of a working configuration file. This, however, still doesn't address the question of what to do about keeping track of each of your changes. Here are a few suggestions.
1. After you have modified a configuration file, and ensured that it works correctly, make a copy of it and number each file consecutively such as:
fvwmrc.01 fvwmrc.02 fvwmrc.03 ...
Comments can be added by starting a line with the # (hash) character and should probably include the date and what modifications were made. If space is a problem, you can compress all the files you are not currently using.
2. Use RCS, the “Revision Control System”, to keep track of your changes. Before you make any changes to the file, run the RCS check-in program:
$ ci -l .fvwmrc
It will ask you for a description of the file; type:
fvwm configuration file .
The . on a line by itself finishes the description.
Then, every time you make a change to the file, run the same command. It will ask you for a description of the change you just made; type something like:
Added Calculator, xjed, and Emacs to the "Application" pop-up menu. .
so that you can find this change later.
RCS keeps track of all the changes you have made to .fvwmrc in a file called “.fvwmrc,v”. Instead of storing a complete copy of each new version of the file, it stores only the changes you have made, plus the latest version of the file.
How do you find the change later? The command line
$ rlog .fvwmrc | less
will give you a history of all the changes you have made. Each change has a revision number, starting at 1.1.
If you want to compare the current copy of the file with the version you previously checked in, use this command:
$ rcsdiff -u .fvwmrc | less
You can retrieve any version of the file you want (overwriting the current version) with
$ co -rrevision .fvwmrc
If you want more information on how to use RCS, it is available with:
$ man rcsintro
which provides a good overview of the concepts and commands you'll need to know. [Linux Journal also published an overview of RCS in issue 10, page 36—ED]
Using the RCS system is only slightly more complex a method of version control than simply making copies of every modified file. However, the basics are easily mastered and can be used for any file—programming project, article, term paper, etc.—that is undergoing sequential revision.
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
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
- SuperTuxKart 0.9.2 Released
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