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
