On Fri, Jan 17, 2003 at 05:42:41PM -0800, Wayne Davison
wrote:> On Fri, Jan 17, 2003 at 04:21:59PM -0800, jw schultz wrote:
> > It should not do /root2/i386/etc/init.d/rsyncd and so on as
> > -R would have it.
>
> -R would only do that if you actually prefixed the paths with the source
> dir, which is not what happens with --files-from. The source dir is
> just used as the default dir. So, your example works exactly as you are
> expecting. I.e, this set of commands:
>
> cd /some/path
> rsync -R `cat /tmp/files` remote:/dest
>
> works much like this new command:
>
> rsync --files-from=/tmp/files /some/path remote:/dest
>
> Except that it also transfers any named dirs in the input file (without
> -r and without recursing). Note also that this reflects the new default
> of -R being enabled by default when --files-from is specified.
>
> If the user wants the extra dirs prefixed from the source spec, they
> just need to specify them as part of the dest:
>
> rsync --files-from=/tmp/files /some/path remote:/dest/some/path
Great! It seems _I_ missed something. I think it is the
difference between the behavior of list items and command
line items that threw me. Sometimes it helps to actually
use an example. We'll have to make sure the manpage is very
clear.
> > I hope this points out clearly the difference in our perspectives on
> > this. I am not talking about a way to extend the command line. I am
> > talking about an explicit list that eliminates the tree walk and
> > awkwardness of artificial include/exclude lists [...]
>
> Sorry, but I don't see any conflict in our perspectives at all. Let me
> know if I'm missing something.
It sounds like the only remaining issues (mostly
implementation detail) are:
implied directories (resolved i think)
when to recourse directories in the list
duplicate dirs
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: jw@pegasys.ws
Remember Cernan and Schmitt
