On 3/29/10 11:45 AM, Sebastien Roy wrote:
On 03/29/10 01:24 PM, Nicolas Williams wrote:
On Mon, Mar 29, 2010 at 01:17:30PM -0400, Sebastien Roy wrote:
Understood, and I see that now. It would indeed make sense to be
consistent and have -H for this subcommand as well.
Agreed. Do you agree re: backslash-escaping?
Yes, but presumably the existing output syntax for -H has already
taken that into account, no? The existing syntax appears to use a
single tab as a separator. I would hope that a tab within a field
would be escaped, and if it's not that should be a bug (otherwise it's
not really parsable).
I could have filenames with ' -> ' in them that would render the
rename
output ambiguous to the human eye. I could have filenames with
'\n<zfs-diff-line>' in the name that would render the output ambiguous
to the human eye.
My intention wasn't to rathole into some absurd discussion over how
to handle ridiculous filenames.
My intention is to avoid security problems in consumers of zfs diff. I
assert that zfs diff is mostly useful only in connection with scripting.
I don't think it's reasonable to expect that zfs diff be useful only "by
eye". It has got to be scriptable because for any sufficiently large
and active dataset the output of zfs diff will generally be too large to
handle "by eye" (sure, you could grep for specific things, but not much
beyond that you're scripting).
(If zfs diff is only useful for scripting then the -H option is actually
unnecessary and zfs diff should always disambiguate pathnames in its
output.)
I don't think it's only useful for scripting. It makes perfect sense
to me to incorporate -H as with other zfs subcommands. Tim, what is
your plan regarding this suggestion?
-Seb
My proposal would be add a -H option. I'm going to say the output
without this option remains
as described, and
++ With the -H option, parseable output is produced. Fields are
++ separated by a single tab, and no '->' is placed between
++ the old and new names of a rename. Whitespace characters, the
++ backslash character, and other characters not in the print
++ class for the locale are represented in the output as a
++ backslash character followed by the three-digit octal
++ representation of the byte value.
++
-tim
_______________________________________________
opensolaris-arc mailing list
[email protected]
