3 ms·
Thanks. The quick fix is to run "LANG=C luit iftop" instead. More detail: The problem is that we've made a design decision not to honor ISO 2022 locking escap
by keithwinstein 15y ago
Thanks.
The quick fix is to run "LANG=C luit iftop" instead.
More detail: The problem is that we've made a design decision not to honor ISO 2022 locking escape sequences (which can be used as line-drawing characters), because they can end up sticking the terminal in permanent hieroglyphs and UTF-8 is supposed to be a stateless, self-synchronizing encoding. (See http://www.cl.cam.ac.uk/~mgk25/unicode.html#term http://www.cl.cam.ac.uk/~mgk25/unicode.html#term for more detail than you probably want, or the examples I just added to mosh.mit.edu.)
We use the NCURSES_NO_UTF8_ACS=1 environment variable to request UTF-8 from ncurses instead of ISO 2022, and 99% of programs honor that -- but iftop is not one of them. It's within its rights, but I think these programs are rare enough that if you want to use the old-style line-drawing characters in mosh, it would be better to run just that program in luit (which is a translator), so that at least when luit exits, you'll be out of hieroglyphs for sure.
- ComputerGuru 15y agoNo go. "LANG=C luit iftop" in mosh or a normal shell is the same result as running iftop in mosh. http://cl.ly/423P2B0u212B0k3j0g0X http://cl.ly/423P2B0u212B0k3j0g0X vs http://cl.ly/0M3f0o2c0O243v3z1N0W http://cl.ly/0M3f0o2c0O243v3z1N0W