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
