On Wed, Feb 06, 2002 at 06:25:05PM -0800, Wayne Davison wrote: > On Thu, 7 Feb 2002, Martin Pool wrote: > > A general-purpose RSYNC_OPTS variable would be more tasteful. I think > > popt makes supporting this fairly straightforward. > > That's a nice idea. One area we'll want to be careful of is how the two > options interact. > > For instance, we want to support old scripts that might set RSYNC_RSH > and then run a bunch of rsync commands. It would be nice to make this > work without conflicting with a user's also-existing RSYNC_OPTS var. A > potential solution is to ignore RSYNC_OPTS if RSYNC_RSH is set (which > also serves to wean people away from RSYNC_RSH if they want to be able > to set other default options). > > Another potential problem area is how to override already-set options. > If someone wants to put -a into their RSYNC_OPTS variable, how can they > then turn it off? I suppose we could just say that the user gets what > she deserves in such a case. > > So, perhaps I'm trying to solve a problem that isn't really all that > important. Just having the ability to set the default remote shell and > its IO mode might be good enough for most people, and we let the rest > use shell scripts or aliases, like you said. > > I could trim down my last patch to avoid the extra RSYNC_RSH parsing if > you'd like to just apply the other part of it. Or, feel free to tweak > it yourself -- it should be pretty easy.
I think a general RSYNC_OPTS option would be difficult to support because of all the options which don't make sense for every invocation. Looking over the list of options, setting the -e and corresponding blocking value is just about the only option I can think people might always want. People can always make a wrapper script to add the options they want, and that would lead to fewer surprises than if some unknowledgable user put something into an RSYNC_OPTS variable and broke somebody else's script. I vote against RSYNC_OPTS. - Dave Dykstra
