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
_______________________________________________
opensolaris-arc mailing list
[email protected]
