[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]