Ellipsis printed in UTF-8 regardless of locale
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| snapd |
Confirmed
|
Undecided
|
John Lenton | ||
Bug Description
Set up some non-UTF-8 locale. E.g. do an "export LC_ALL=
Execute "snap list" and check the "Tracking" column.
Notice that what is "stable/…" in case of UTF-8 settings becomes "stable/â¦" instead, and subsequent columns are misaligned.
Redirecting the output to a file and examining its hex dump (or opening in a UTF-8 editor) reveals that the the ellipsis "…" was still emitted in UTF-8.
The output should not encode text according to what's not the locale's (terminal's) encoding. If the ellipsis is not representable in the current locale, using three dots "..." might be a good solution.
In my personal opinion, it is reasonable if a new project decides to support UTF-8 only and doesn't wish to bother with legacy encodings. A warning in case the encoding is not UTF-8 would be nice, though. Also, if this is a decision that this project makes then this should be followed for bug 1830051 too, and just print the UTF-8 tick unconditionally over there.
snapd version 2.38+19.04 on Ubuntu 19.04.
| John Lenton (chipaca) wrote | #1 |
| Changed in snappy: | |
| status: | New → Confirmed |
| assignee: | nobody → John Lenton (chipaca) |
| affects: | snappy → snapd |
it's a bug that the ellipsis is printed when unicode is false (be it autodetected from TERM and the locale, or be it via --unicode=never); in the same way we change the tick to an asterisk, we should have a fallback for the ellipsis in the channel.
It's an oversight; I'll fix it.
A lot of text from snapd is going to be in utf8 however, and this won't catch everything. For example, if in a non-utf8 locale, "snap info unifonter" is going to look interesting.