For automatic updates and commits, I have written a very simple Perl program, maintain.pl. The longest part of the program is the help text, so you can imagine it's not full of complex code. I will go through it regardless, but keep in mind that a shell script could do the same job if needed.

The only thing maintain.pl does not do is make the symbolic links. Since that has to be done just once, and on some systems you do not want the links wholesale, the complexity of the task compared to the simplicity of doing it manually was simply too much. I know because I wrote the symbolic link code and got rid of it later.

I had to write and maintain yet another configuration file that mapped out many filenames. There were many exceptions; for example, two Linux and Solaris systems I use have radically different setups. There were just too many things to worry about, and I found that manually installing the links was much easier. Of course, your experience may vary -- I encourage you to try to find the most appropriate approach for your own environment.

The maintain.pl script begins with the usual definition of configuration options, loading of command-line arguments, and help text.

Listing 7. Preliminaries in the maintain.pl script

#!/usr/local/bin/perl -w

# {{{ modules and constants
use strict;
use AppConfig qw/:expand :argcount/;
# }}}

$| = 1;       # autoflush the output

my $config = AppConfig->new();
$config->define(
 'HELP'     =>
 { ARGCOUNT => ARGCOUNT_NONE, DEFAULT => 0, ALIAS => 'H'},
# update level, higher checks out more
 'LEVEL'    =>
 { ARGCOUNT => ARGCOUNT_ONE,  DEFAULT => 5 },
 'CONFFILE' =>
 { ARGCOUNT => ARGCOUNT_ONE,  ALIAS => 'F',
   DEFAULT => glob("~/config/maintain.conf") },
 'CVS'      =>
 { ARGCOUNT => ARGCOUNT_ONE,  DEFAULT => 'cvs' },
 'CVS_RSH'  =>
 { ARGCOUNT => ARGCOUNT_ONE,  DEFAULT => 'ssh' },
 'UPDATE'   =>
 { ARGCOUNT => ARGCOUNT_HASH },
 'DRYRUN'   =>
 { ARGCOUNT => ARGCOUNT_NONE, DEFAULT => 0, ALIAS => 'N' },
 'COMMIT'   =>
 { ARGCOUNT => ARGCOUNT_NONE, DEFAULT => 0, ALIAS => 'C' },
);

$config->args();
if (-r $config->CONFFILE() && -f $config->CONFFILE())
{
 $config->file($config->CONFFILE());
}
else
{
 print "The file " . $config->CONFFILE() .
       " was not readable, skipping\n";
}

if ($config->HELP())
{
 print <<EOHIPPUS;

$0

Run $0 without any arguments to load
@{[$config->CONFFILE()]}
and update everything in it at level
@{[$config->LEVEL()]} or less.

Switches:
 -level (default @{[$config->LEVEL()]}) :
   check out everything at this level or less

 -help (-h) : print this help

 -conffile (-f, default @{[$config->CONFFILE()]}) :
   load this configuration

 -cvs (default @{[$config->CVS()]}) :
   where to find the cvs program

 -cvs_rsh (default @{[$config->CVS_RSH()]}) :
   sets the CVS_RSH environment variable

 -update : populate the UPDATE hash in the configuration
           file or like this:
           -update /home/tzz/           see below for explanation

 -commit (-c) : don't just update, also do a commit of
                anything changed

 -dryrun (-n) : don't run anything, just test directories
                and levels

Configuration file:

Very simple AppConfig format; everything in the switches can be
specified in the configuration file as well, e.g.

COMMIT = 1
UPDATE /home/tzz/config = 0

The example above says that /home/tzz/config will be updated at level

0 or higher, and that you always want to commit when you run this

program.

EOHIPPUS

 exit 0;

}

$ENV{CVS_RSH} = $config->CVS_RSH();

If you are unfamiliar with the AppConfig module, you should check out the Resources section for useful info on managing configurations.

I do a glob() call to determine the default CONFFILE, because the user's home directory could be anywhere. If the CONFFILE contains invalid data, AppConfig automatically kills the whole program (this can be changed to be just a warning). The script can even run without a configuration file.

After printing out the help text, I set the CVS_RSH environment variable to the appropriate value (defaults to ssh). This is so that the user does not have to set that environment variable in some other way, which is especially convenient for users who put maintain.pl in their crontab.

After all these preliminaries, let's look at the heart of the script:

Listing 8: main loop of maintain.pl

foreach my $spot (keys %{$config->UPDATE()})
{
 my $level = 0 + $config->UPDATE()->{$spot};
 next if $level > $config->LEVEL();
 print "Spot $spot, Level $level\n";
 chdir $spot;
 if ($config->DRYRUN())
 {
  print "Not updating due to DRYRUN\n";
 }
 else
 {
  system($config->CVS() . " -q update");
 }

 if ($config->COMMIT())
 {
  if ($config->DRYRUN())
  {
   print "Not committing due to DRYRUN\n";
  }
  else
  {
   system($config->CVS() . " commit -m ''")
  }
 }

}

This is a simple loop. I run through every spot, which is really a directory, and do a cvs update if the spot's level is less than or equal to the LEVEL configuration variable, defaulting to 5. In addition, if the COMMIT flag is set, I do a cvs commit -m '', which commits all changes with an empty log message. In fact, if it weren't for the DRYRUN flag, this loop would be just a few lines long.

I use system() with the string form instead of the multiple argument form. You could do it the second way -- see perldoc -f system for details on the usage of this function call.

Also, I don't check the result of the system() call, because it's unnecessary. There's nothing maintain.pl can (or should) do in the case of a CVS update or commit problem, since these are crucial configuration files we don't want to update blindly.

The configuration file is simplicity itself:

Listing 9. maintain.conf

# the number is the update level
UPDATE /home/tzz/emacs = 0
UPDATE /home/tzz/config = 0
UPDATE /home/tzz/articles = 1
UPDATE /home/tzz/gnus/gnus = 1

Remember you can set any AppConfig variable here, so you can override the default LEVEL or CVS_RSH, for instance. I update my Emacs, config, articles, and gnus directories through maintain.pl, but their update levels are different to reflect the frequency with which I update (I do level 0 twice every day and level 1 once daily).

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