Hacker News new | past | comments | ask | show | jobs | submit login

Note (for keithwinstein?):

mosh doesn't handle iftop output properly. It may be that iftop abuses UTF8 or takes advantage of a bug to print certain characters, but it's not working right with mosh.




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 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.


No go. "LANG=C luit iftop" in mosh or a normal shell is the same result as running iftop in mosh.

http://cl.ly/423P2B0u212B0k3j0g0X vs http://cl.ly/0M3f0o2c0O243v3z1N0W




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: