On 03/29/10 12:33 PM, Nicolas Williams wrote:
On Mon, Mar 29, 2010 at 12:23:56PM -0400, Sebastien Roy wrote:
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.
Taking a step back here, this subcommand is not the only zfs
subcommand whose output could be subject to parsing by scripts.
Many zfs sub-commands already have a -H option ("Display output in a
form more easily parsed by scripts").
Ah, indeed.
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).
Therefore I don't think your argument carries water. My request is not
generalizable because ZFS already has parseable output support.
Understood, and I see that now. It would indeed make sense to be
consistent and have -H for this subcommand as well.
If
you think there is something that is ambiguous to the human eye,
then I think that's in scope.
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.
-Seb
_______________________________________________
opensolaris-arc mailing list
[email protected]
