Sebastien Roy wrote: > 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.
It's not uncommon to have an additional option to a command (stty -g for example) which produces easily-parsable (and not necessarily easily readable :) ) output for this situation. Steve
