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