Date: Thu, 4 Jan 2001 10:22:38 -0600
From: Dave Dykstra <[EMAIL PROTECTED]>
I like that idea. I would call it "--only-from".
One corner case to consider is: What happens when one of the
pathnames in the list turns out to be a directory? My advice it to
keep it absolutely as simple as possible and warn about it, but take
no other action for that particular pathname. In other words, leave
it up to the source of the pathname list to properly get rid of
directories, rather than suddenly opening up the same can of worms
that rsync already has by getting fancy about what to do with
directories, inclusion, exclusion, etc etc.
I feel very strongly that the confusing semantics of the current
include/exclude logic is one of rsync's most serious problems. This
seems fairly obvious just by inspection---the vast majority of mail to
the list is either (a) "why did/didn't this particular set of files
get mirrored, and how do I fix it?" and (b) "why did rsync hang?".
It thus seems like we could remove half of the user confusion (and
traffic to this list) simply by letting rsync depend on tools for
which the semantics has already been worked out and well-documented
and which might allow people to carry over knowledge from other
domains to rsync. Thus, people who understand how find works can use
find (and can use find... -ls to check what's going to happen before
handing it to rsync!); people who prefer to use perl to do such things
can use that, etc etc. No matter how well worked-out rsync's semantics
are wrt inclusion/exclusion, it's Just One More Language And Learning
Curve for people to deal with---which is one of the major problems
with tools under Unix, wherein each and every application tends to
make the user learn of -its- special configuration file, exceptions to
quoting rules in config and use, weird little auxilliary scripting
languages, etc etc. If they'd -like- to learn a special language for
how to specify files, they can use the existing rsync semantics. But
otherwise, they can feed it a list of files and leave it at that.
(And by the way, I'd argue that --files-from= makes more sense than
--only-from=, for two reasons: (a) it matches things like GNU tar,
and hence is easier to remember, and (b) it emphasizes that it's
-files- we're after here, not directories. If the intent it to ensure
that users understand that nothing -but- the files specified as an
argument will be transferred, you could try changing its name to
--files-only-from=, but I'd argue that this is unnecessary---tar users
don't get confused by this, and it's easy to document.)
This would go a long way towards making rsync -feel- like an API, even
though it's not a clean way to do it (since it should be callable via
real function calls, not by having to exec it in its own process and
feed it files and options that way).
