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 BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: https://github.com/backuppc/backuppc/wiki Project: https://backuppc.github.io/backuppc/