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
