On 11/01/2013 12:02 PM, Pádraig Brady wrote: > On 11/01/2013 05:39 PM, Eric Blake wrote: >> On 11/01/2013 10:29 AM, Pádraig Brady wrote: >>> This should be fully backwards and forwards compatible with previous >>> escaping, since we'll never have a file name at the start of a line, >>> thus '\' at the start of a line always means the file name is escaped. >> >> This feels like it could be a step in the wrong direction to me. I've >> been arguing that we need to escape file names containing \r, for the >> sake of people that transmit files with \r\n line endings compared to >> files that contain a literal trailing \r. > > I can see the need for that yes. > > Though I don't think avoiding the redundant escaping > of file names with just '\' characters would impact that?
Indeed, after thinking a bit more, I think your proposal still makes sense; we have an unambiguous marker at the front of the line telling us whether escape processing is employed for the rest of the line. And as long as we are changing the output, we might as well make the one release change all output at once (back to the argument of the NEWS-worthy mention that output between older versions and newer is not identical, even though newer versions will continue to correctly parse older version). It may be sufficient to just check for newline anywhere, or carriage return as final byte, as the two conditions that warrant escaping. I guess that means I should try and make some time to actually write my \r patches that I've been rambling on about for several years. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
