1

rsnapshot / rsnapshot.conf.default.in now has quite a few settings of the form @setting@, but there's no indication anywhere what those settings decode to. For example @CMD_CP@ doesn't seem to be interpreted anywhere in the repository to some use of cmd_cp, and isn't mentioned at all in these guides:

Am I missing something obvious?

0

1 Answer 1

3

The rsnapshot.conf.default.in file is a template for the rsnapshot.conf.default file. It contains various placeholder values in the form @NAME@ that the configure script replaces during project build preparation.

Typically, these placeholders are replaced with strings (pathnames, etc.) that are specific to the system on which the project is being built.

You would not have to deal with this template file at all, but rather with the generated file, if you install the rsnapshot utility via a package on your Linux system, e.g., via apt, apk, yum, or a similar package manager. This would likely install a configuration file, or an example configuration file, with sane defaults for your Linux distribution.

Having said that...

Following the first few build and installation instructions found in the INSTALL.md file (on my Alpine Linux system):

$ ./autogen.sh configure.ac:2: installing './install-sh' configure.ac:2: installing './missing' $ ./configure [...] $ ls -l rsnapshot.conf.default* -rw-r--r-- 1 myself myself 8680 Nov 25 07:50 rsnapshot.conf.default -rw-r--r-- 1 myself myself 8611 Nov 25 07:42 rsnapshot.conf.default.in 

Investigating the generated rsnapshot.conf.default file will show you that @CMD_CP@ has been replaced with cmd_cp /bin/cp (if /bin/cp is the path to the cp utility on your system). Why? Because the configure script says that

CMD_CP="cmd_cp $CP" 

... where CP is a variable holding the path to the found cp executable, and it's substituting all instances of @CMD_CP@ found in the files it's processing with that value.

For the autoconf M4 macro script that came to that conclusion:

dnl if the user didn't specify a path, hunt for it if test "$CP" != "no"; then AC_PATH_PROG(CP, cp, no) fi dnl if we couldn't find it, provide an example if test "$CP" = "no"; then CP=/bin/cp fi dnl either way, set the cmd_cp var AC_SUBST(CMD_CP, "cmd_cp $CP") 

(That's from configure.ac, the autoconf script of M4 macros that are a bit easier to read than the final configure shell script. The configure script is generated from configure.ac by autoconf when you run autogen.sh.)

AC_PATH_PROG is an autoconf macro that finds the path of the given program (the 2nd argument, cp in this case) and sets the given variable (the 1st argument, CP) to that value, or to no (3rd argument) if it was not found. You can see from the code that it will use /bin/cp if that's where cp is on your system, or if it can't find the cp executable.

AC_SUBST is another macro that, in this case, ensures that @CMD_CP@ will be replaced by the given string in the files handed to the AC_CONFIG_FILES macro a bit further down in configure.ac.

The comment "if the user didn't specify a path" refers to the fact that the preceding code in configure.ac handles the case where configure is run with --with-cp=... to specify a non-standard pathname for the cp utility (useful if you have several variants of the base utilities installed).

3
  • As we are expected to directly manipulate /etc/rsnapshot.conf we subsequently have no way of checking it if we've messed up that file or if it needs updating when the whole package is updated other than looking at rsnapshot.conf.default.in. Seems to me the explanation at rsnapshot/rsnapshot could be improved to explain these placeholders. Commented Nov 26 at 20:33
  • In the case of Arch Linux, svntogit-community/trunk/PKGBUILD gives no clues as to how the conversion from the placeholders is done. Commented Nov 26 at 20:33
  • 1
    @joharr If you’re going so far as looking at the autoconf template file in the project’s GitHub repository, then I think it would be fair to say that it be a shorter and less painful way to go to use the utility with a local copy of the configuration file. If you need to keep track of changes to files under /etc, you could even consider using something like etckeeper. You could also consider submitting a patch to the Arch package so that installs the default configuration as an example file instead of overwriting the real configuration. Note, I know nothing of Arch Linux. Commented Nov 26 at 21:08

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.