Date: Mon, 8 Jul 2002 21:18:18 +0800 From: Adrian Ho <[EMAIL PROTECTED]>
If the sender's/receiver's cwd is guaranteed to be the root of the corresponding rsync'd hierarchies, then yes, relative paths would suffice. > <example> > UPDATE foo/ > CREATE foo/bar1 > UPDATE foo/oldie > DELETE foo/gonzo > HLINK foo/gorgon > SLINK foo/plank > SPECIAL foo/sock1 > </example> I like the format. I don't, unless pathnames with newlines in them are already explicitly disallowed. Otherwise, things become ambiguous. If the format was just a list of pathnames, they could be null-terminated, and the -0 arg to xargs could be used, as is recommended when handling general lists of filenames. (After all, under Unix at least, no filename may contain a null, whereas it -is- legal, though hardly recommended, for a filename to contain a newline.) However, doing this makes handling the keywords (e.g., using grep on them) much trickier. It also means that every script that has to handle a particular kind of file (updated, deleted, etc) has to prefilter its input. OTOH, this might be a better approach than having a separate command-line arg for each type of file and every phase, e.g., you'd have to have post-send-deleted=, post-recv-updated, etc etc, leading to a large number of additional options. (The additional options also make it slightly harder to have a single logfile that accumulates them all, but easier to have a logfile that accumulates only one type.) I'm not sure which way people think about either the null issue or the script-filtering-vs-extra-command-line-args issue, but I figured I'd point them out. Similarly, when --files-from= is finally implemented, it will also have to decide whether the names are newline-terminated or null-terminated. If the former, then the documentation will have to explicitly say that there are just some pathnames that it won't be able to handle, and why. And no, I myself have no pathnames like that, but I believe in being defensive about such things when I can be. It's a pity that Unix semantics wrt naming and termination interact to make this so inconvenient. Given all this, I think a cleaner solution would be something like a spiffier version of --log-format. My suggested format directives borrow from the feel of recent versions of "date", and might look like the below. (And I'm -not- wedded to the specifics of the syntax & letters here---in fact, I think my example syntax is awful.) % starts a directive 0 prepended to any directive, it null-terminates the resulting string @ ("action") takes a subdirective, and applies to the relevant action: D delete C create U update etc P the pathname (maybe P = absolute & p = relative?) ? ?what other options do we want here? and... %( %) grouping (see below) Thus, if you said (oh ugh): --log-format="%@D%(DELETED\t%P\r%)%@0C%(I made one!-->P\r%)" you might see this in your log: DELETED /foo/bar DELETED /blah/biff I made one!-->/etc/splat and no lines at all for updates or any other actions. Yes, it's stupid to have some lines null-terminated and some null-and-newline terminated; I'm just doing this as an example. And maybe it's better to have a multiplicity of options than the awful fake-conditional syntax I introduced above. It'd certainly be more readable. (Where I'm going with this is something like Common Lisp's FORMAT function, which parses a string a la printf, but where the string can have embedded conditionals and is its own little language. While I hate inventing little languages and hate other applications forcing me to learn theirs, there -is- a benefit here, namely that we might be able to define something general enough that it would help most of the people who need something like that.) If there were some mechanism to put different --log-format results in different places, it would be nice if multiple --log-format occurrences would all be allowed, but then the syntax might be even uglier: --log-format="%@0DP"=/tmp/deleted-files --log-format="%@0UP"=/etc/updated-files would put a null-terminated list of deleted files in /etc/deleted-files, and a null-terminated list of updated files in /etc/updated-files. Maybe someone will think some of these ideas are worth pursuing... -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html