On 03/29/10 12:14 PM, Nicolas Williams wrote: > On Sun, Mar 28, 2010 at 01:12:16PM -0600, Tim Haley wrote: >> + If the modification involved a change in the link count of a >> + file, the change will be expressed as a delta within >> + parentheses on the modification line. Example outputs are >> + below: >> + >> + M /myfiles/ >> + M /myfiles/link_to_me (+1) >> + R /myfiles/rename_me -> /myfiles/renamed >> + - /myfiles/delete_me >> + + /myfiles/new_file > > Is there any escaping of whitespace and non-printable characters in the > pathnames? If not then the above format is ambiguous and cannot be > safely scripted. > > There are several ways that you could address that problem, such as > escaping (HTML/XML entities? backslash escapes? pick your poison), > adding a length field preceding either each path or each path that > contains whitespace, or use a multi-line (for renames) format with paths > being the last field such that you need only [backslash?-]escape > newlines. > > Probably the simplest answer is backslash-escaping whitespace, since > shells can handle that trivially. That is what I recommend.
Taking a step back here, this subcommand is not the only zfs subcommand whose output could be subject to parsing by scripts. Adding parsable output should be something that is thought-through for the entire suite of subcommands (and zfs-related commands) so that there is a uniformly applicable solution. IMO, that's not this case (although that's ultimately the project team's decision). If you think there is something that is ambiguous to the human eye, then I think that's in scope. -Seb
