Craig,
digging around a bit,
it appears,
$Conf{DumpPreUserCmd}
$Conf{DumpPostUserCmd}
$Conf{DumpPreShareCmd}
$Conf{DumpPostShareCmd}
are declared as single value string types,
./lib/BackupPC/Config/Meta.pm
DumpPreUserCmd => {type => "string", undefIfEmpty => 1},
DumpPostUserCmd => {type => "string", undefIfEmpty => 1},
DumpPreShareCmd => {type => "string", undefIfEmpty => 1},
DumpPostShareCmd => {type => "string", undefIfEmpty => 1},
whereas
RsyncShareName => {
type => "list"
&
ClientShareName2Path => {
type => "hash"
if
DumpPreShareCmd
DumpPostShareCmd
were, instead, similarly hash types, with
key: (RsyncShareName)
value: 'cmd string'
then, if 'cmd string' would exec for current $share, if def'd, otherwise a
default value (e.g., DumpPreShareCmdDefault)
and, all of
(current)$share
matching ClientShareName2Path value (if any)
matching 'cmd string' (if any)
were available and could be cleanly passed 'out' to an external script, in 'cmd
string',
that might provide a convenient approach the "treat each share differently"
framework.
i.e., each share could have BOTH a unique share->path map, AND a unique
Pre/PostShare cmd.
thoughts?
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/
