Subject: Re: bug#32236: df header corrupted with LANG=zh_TW.UTF-8 on macOS

From: Paul Eggert <[email-masked]>
Date: Sun, 22 Jul 2018 10:01:09 -0700

Pádraig Brady wrote:
> I did want to only avoid \n etc. that might cause issues for
> programs that parsed output from df on a line by line basis.
> This subset of control characters is safe to identify
> It seems problematic to start eliding improperly encoded
> mount points for example, rather than just outputting
> what's there.

Yes, I suppose you're right, it's not df's job to police encodings.

> Also just incrementing width++ per each wide character
> doesn't seem right, though again I've not tested it.

True as well. OK, please ignore my patch.

I was prompted by worries about multibyte encodings that use bytes that could be 
misinterpreted as ASCII control characters, such as a locale that uses EBCDIC 
encoding. However, that's probably just a theoretical concern; no coreutils 
users use EBCDIC any more, right? Plus there are doubtless lots of other places 
in coreutils that assume '\n' is a newline in encoded text.