I just noticed that there is an extra blank line in the output generated by rsync when the --dry-run (-n) flag is used. This seems to have started with 2.6.0. Is this desired? The reason why I'm asking is because I use scripts that parse the output from rsync and little modifications in verbosity can make or break things easily. Thanks, -- Alberto [ads@localhost bin]$ rsync-2.5.7 -an rsync://adswon.cfa.harvard.edu/pre/load/current/ /home/ads/abstracts/pre/latest/ receiving file list ... done wrote 78 bytes read 1204 bytes 2564.00 bytes/sec total size is 457622413 speedup is 356959.76 [ads@localhost bin]$ rsync-2.6.1 -an rsync://adswon.cfa.harvard.edu/pre/load/current/ /home/ads/abstracts/pre/latest/ receiving file list ... done wrote 78 bytes read 1204 bytes 2564.00 bytes/sec total size is 457622413 speedup is 356959.76
On Wed, Jan 28, 2004 at 12:38:11PM -0500, Alberto Accomazzi wrote:> I just noticed that there is an extra blank line in the output generated > by rsync when the --dry-run (-n) flag is used. This seems to have > started with 2.6.0. Is this desired? The reason why I'm asking is > because I use scripts that parse the output from rsync and little > modifications in verbosity can make or break things easily.Yes it is desired. It also got a mention in NEWS. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt
On Wed, Jan 28, 2004 at 12:38:11PM -0500, Alberto Accomazzi wrote:> I just noticed that there is an extra blank line in the output generated > by rsync when the --dry-run (-n) flag is used. This seems to have > started with 2.6.0. Is this desired?The NEWS file has this (understated statement) to say about it: * Various trailing-info sections are now preceded by a newline.> The reason why I'm asking is because I use scripts that parse the > output from rsync and little modifications in verbosity can make or > break things easily.One of the benefits of having the blank line is that it makes it easier to stop processing the list of changes before you get to the footer data. For instance, imagine someone creating a directory with the name "wrote 8 bytes read 4 bytes 4.00 bytes" and then putting a file named "sec" in it. (Yes, the current code is vulnerable to someone putting a newline into a filename, but we should really fix that in the same way that ls does.) So, this change does mean that any scripts that process the verbose output will need to be tweaked to handle the new blank line. However, I don't foresee any other changes being made to the verbose output (since we are cognizant of the fact that people do parse it). ..wayne..
On Wed, Jan 28, 2004 at 12:38:11PM -0500, Alberto Accomazzi wrote: | I just noticed that there is an extra blank line in the output generated | by rsync when the --dry-run (-n) flag is used. This seems to have | started with 2.6.0. Is this desired? The reason why I'm asking is | because I use scripts that parse the output from rsync and little | modifications in verbosity can make or break things easily. While I understand your concern, the design of programs like rsync is for humans to read the results, not for machines. That said, I think it might be nice for there to be an option to specify a filename to store final status information in that is orthogonal to any human readable verbosity. The format of that status should be easy for parsing to be applied, perhaps in "name=value" format, one per line. wrote=78 read=1204 bytes/sec=2564.00 totalsize=457622413 speedup=356959.76 exitstatus=0 However, this would be a lot of work for the rsync developers for not a lot of gain, so I don't think it would likely be adopted. Maybe you can write a patch for it. I might if I get the time. When I run rsync, I do like to be able to run in via screen or a headless virtual console, where I can spy on the current running any time I want. Adding the ability to have a script extract that info, while still being able to see normal stdout and stderr output, would be good. -- ----------------------------------------------------------------------------- | Phil Howard KA9WGN | http://linuxhomepage.com/ http://ham.org/ | | (first name) at ipal.net | http://phil.ipal.org/ http://ka9wgn.ham.org/ | -----------------------------------------------------------------------------