Date: Sat, 11 Nov 2017 20:22:35 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 223598] ls utf output Message-ID: <bug-223598-8-mkxsSSDBnS@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-223598-8@https.bugs.freebsd.org/bugzilla/> References: <bug-223598-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D223598 --- Comment #6 from bsd@haps.ca --- Ah, this is all very interesting, the -w option seems to be exactly what is needed. It seems further that the LANG setting will cause a re-interpretat= ion of what is 'printable'. However, maybe I'm just confused about this, but it seems unlikely that 'ls' should try to determine what is 'printable' beyond truly unprintable characters (control chars, etc). In reality, support by a font would be more indicative of what is printable, and ls would have no way of determining that. The fact that -w shows print= ed characters on my linux terminal, but not on my freebsd terminal, is due to = the font support. It still seems to me 'bug'-ish that without any locale, printable but non-a= scii characters are converted to '?'. It seems counter-intuitive that a charact= er belonging to a different alphabet would be considered 'non-printable'. The characters that come to mind as 'non-printable' are things like CR, LF, EOL. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-223598-8-mkxsSSDBnS>