Home arrow Perl Programming arrow Page 4 - Cultured Perl: Managing Linux Configuration Files

Organizing your new configuration - Perl

CVS backs up, distributes, and simplifies your configuration files. In this article, Teodor Zlatanov discusses how to save time, energy and frustration when working with Linux configuration files by using your CVS tree. (This introductory-level article was first published by IBM developerWorks, June 10, 2004, at http://www.ibm.com/developerWorks).

TABLE OF CONTENTS:
  1. Cultured Perl: Managing Linux Configuration Files
  2. Setting up CVS
  3. Automatic updates and commits
  4. Organizing your new configuration
  5. Conclusion
By: developerWorks
Rating: starstarstarstarstar / 6
November 24, 2004

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

This section will cover my personal experiences with using the configuration system you've set up so far. Take ideas freely, but remember that my personal setup is not right for everyone.

I keep directories based on machines and operating systems, as specific as they need to be. For instance, I keep my Linux-specific configurations under "linux" but, because my home machine "heechee" has a specific keyboard, I have a heechee directory as well for the heechee-specific configurations.

The overriding rule, though, should be that if you can express a configuration in one file instead of multiple versions for multiple platforms, do it. Otherwise you'll spend most of your time maintaining two or more versions of the same file, and that's not fun.

Let's start with an example from my cshrc file, which has one version for all machines. I take advantage of the C shell language's built-in decision logic to make alternate decisions:

Listing 10. Define the precmd for various platforms

switch ($OSTYPE)
 case "solaris":
 case "SunOS":
  alias precmd '/bin/echo "\033]0;${HOST}:$cwd\007\c"'
 breaksw
 case "linux":
  alias precmd 'echo -n "\033]0;${HOST}:$cwd\007"'
 breaksw
endsw

The commands above specify different versions of the same thing. The Linux echo needs an -n switch to avoid printing a new line, while the Solaris version needs a \c at the end of the string. The effect of this is to set the title of an xterm window to HOST:/DIRECTORY whenever a prompt is printed.

Clearly, whenever you can make decisions in the configuration file itself, you usually don't need to make multiple versions of the same file in distinct directories. My Emacs configuration, for instance, has just one version for all six or so varieties of machines I use regularly -- and some of them are running Emacs 20, which is many years old!

Sometimes you do have to do some splitting. The xmodmaprc file, for instance, sets up mapping between keycodes and key names (among many other things it can do). I keep a version for my home machine in ~/config/heechee/xmodmaprc and another version in ~/config/sun/xmodmaprc for all the Sun machines I use. There is no logic in the xmodmaprc format, so splitting it is the only recourse. I did, however, create just one xmodmaprc file for all the Sun machines, because all of them have the same keyboard model.

The crontab file (which I keep in ~/.crontab and periodically reload into crontab) is an extreme example of a configuration file that needs to be specific to each machine. The crontab from my home machine would be inappropriate for any other machine, and there is no logic in the standard crontab format to choose between cron jobs based on anything other than time.

The bottom line is that you should figure out if multiple versions of a configuration file are needed, and then decide the best way to organize those multiple versions. Your goal should be to have a consistent environment, not to spend hours upon hours writing and maintaining configuration files. I hope the techniques explained in this article prove useful in your search for configuration Nirvana.

IBM developerWorksVisit developerWorks for thousands of developer articles, tutorials, and resources related to open standard technologies, IBM products, and more. See developerWorks.



 
 
>>> More Perl Programming Articles          >>> More By developerWorks
 

blog comments powered by Disqus
   

PERL PROGRAMMING ARTICLES

- Perl Turns 25
- Lists and Arguments in Perl
- Variables and Arguments in Perl
- Understanding Scope and Packages in Perl
- Arguments and Return Values in Perl
- Invoking Perl Subroutines and Functions
- Subroutines and Functions in Perl
- Perl Basics: Writing and Debugging Programs
- Structure and Statements in Perl
- First Steps in Perl
- Completing Regular Expression Basics
- Modifiers, Boundaries, and Regular Expressio...
- Quantifiers and Other Regular Expression Bas...
- Parsing and Regular Expression Basics
- Hash Functions

Developer Shed Affiliates

 



© 2003-2013 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap

Dev Shed Tutorial Topics: