bug#11922: df doesn't handle \n in mount entries appropriately

[Jim Meyering]

Pádraig Brady wrote:
> 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 '?'.
...
>
> * src/df.c (hide_problematic_chars): Replace '\n' with '\?'.

Thanks.  That looks fine, but shouldn't the '\?' above be just '?'

> * NEWS: Mention the fix.
> ---
>  NEWS     |    5 +++++
>  src/df.c |   24 +++++++++++++++++++++++-
>  2 files changed, 28 insertions(+), 1 deletions(-)
>
> diff --git a/NEWS b/NEWS
> index b8d3cbb..b4bd7e4 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -13,6 +13,11 @@ GNU coreutils NEWS                                    -*- 
> outline -*-
>    date: invalid date '\260'
>    [This bug was present in "the beginning".]
>
> +  df no longer outputs '\n' characters present in the mount point name.
> +  Such characters are replaced with '?' so for example, scripts consuming
> +  lines output by df, can work reliably.
> +  [This bug was present in "the beginning".]