Wayne, I've been experimenting with the {pre,post}-xfer exec options ever since the original diff showed up in patches/ - fantastic stuff. My feature request/change centers around the new RSYNC_ARG# variables. Would it be possible to make these available as an array (ie: ${RSYNC_ARG[#]}) rather than discrete variables? If nothing else, it would greatly simplify chewing through all the args for whatever processing one could dream up. Erik
Wayne, How about per module logging as an option, instead of global. Master Erik Jan Tromp wrote:> Wayne, > > I've been experimenting with the {pre,post}-xfer exec options ever since the original diff showed up in patches/ - fantastic stuff. > > My feature request/change centers around the new RSYNC_ARG# variables. Would it be possible to make these available as an array (ie: ${RSYNC_ARG[#]}) rather than discrete variables? If nothing else, it would greatly simplify chewing through all the args for whatever processing one could dream up. > > Erik >
On Mon, Mar 13, 2006 at 04:55:49AM -0500, Erik Jan Tromp wrote:> My feature request/change centers around the new RSYNC_ARG# variables. > Would it be possible to make these available as an arrayThere is not a portable way to represent an array in the environment. This means that if you want an array, you need to create it yourself. For instance, in zsh we could do something like this to turn the args into an array: #!/bin/zsh arg=() for x in RSYNC_ARG{1..99}; do [ ${(P)+x} = 0 ] && break arg+=(${(P)x}) done print -l $arg # prints the array $arg with one item per line I chose to skip the RSYNC_ARG0 arg (which is always "rsyncd") because zsh numbers its arrays starting with 1, and this makes $arg[1] the same as RSYNC_ARG1. ..wayne..
Possibly Parallel Threads
- server feature request. forced backup
- To inc_recurse or not to inc_recurse? [Re: 3.0.0pre2: bookend breakage (2 different errors)]
- non-recursive remote listing breakage in 3.0.0pre1
- Cleanest way to find out if it was a --dry-run
- Need clarification of documentation