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.
