|
From: | Paul Eggert |
Subject: | bug#32236: df header corrupted with LANG=zh_TW.UTF-8 on macOS |
Date: | Sun, 22 Jul 2018 10:01:09 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |