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/

Reply via email to