On 07/12/2012 05:11 PM, Pádraig Brady wrote:
> On 07/12/2012 04:35 PM, Paul Eggert wrote:
>> On 07/12/2012 08:28 AM, Pádraig Brady wrote:
>>> more problematically it would change the output from
>>> the lib
>>
>> Ah, sorry, I was talking only about df's output,
>> independently of how it gets the info from the underlying
>> library.  Surely the C library API should return a string
>> with raw newlines etc. in it, leaving it up to 'df' how to
>> display it?
>>
> 
> Oops, right.
> I misread "with the lower level" as "in the lower level" :)
> 
> So just considering df, the tradeoff is ambiguous
> output in the presence of \n when just escaping \n,
> or unambiguous output which is backwards incompatible
> in the presence of <space>,<tab>,<newline>.
> 
> It's interesting that the low level interface only
> considers the above 3 chars. I guess that's so
> that _programs_ can use isblank() and getline() to
> parse the output robustly.
> However it might be better for df to escape all
> control characters (\r,\f,...) so that _humans_
> can parse too.

That attached patch takes the simplest approach
and just replaces '\n' with '?'.
Reasons are detailed in the commit message.

I was considering doing something a bit more general,
along the lines of unicode_displayable() in fslint:
http://code.google.com/p/fslint/source/browse/tags/2.42/fslint-gui#92
While that could be generally useful within coreutils,
I've gone with the simpler approach for now.

cheers,
Pádraig.