Cultured Perl: Managing Linux Configuration Files - Organizing your new configuration (Page 4 of 5 )
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.
 Visit developerWorks for thousands of developer articles, tutorials, and resources related to open standard technologies, IBM products, and more. See developerWorks.
|
Next: Conclusion >>
More Perl Articles
More By developerWorks
/ 6 
