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".]
