Hi Nicholas, Nicholas Marriott wrote on Fri, May 19, 2017 at 07:27:36PM +0100:
> ksh has problems for me with Anton's example in several terminals, > not just in tmux. Mostly the cursor seems to end up one character > off rather than in the prompt, which is less visibly incorrect > perhaps, but still wrong. Can't reproduce. At least when having LC_CTYPE=en_US.UTF-8 set when starting the terminal, there is no problem for me with Anton's example in xterm, urxvt, gnome-terminal, or konsole. If i type echo xx then left-arrow, a width-one non-ASCII character, a dot, and hit enter, the dot appears at the right place both on the command line and in the output. Moving around with arrow-left or arrow-right after typing the non-ASCII character to insert the dot at a different place doesn't break anything for me either. The output is correct even with tmux, all that tmux garbles is the command line display. On a side note, i don't think gnome-terminal and konsole are relevant. I never installed them before and did so now for the first time for testing, but they installed so many libraries that i feel uncomfortable and unsafe using them even briefly and purely for testing purposes. I will certainly pkg_delete them, and the libraries they pulled in, in the near future. I can't believe anyone in their right mind would use a terminal depending on webkit, json, javascript, geoclue, pulseaudio, polkit, libssh and the like for any serious work (and on top of that, konsole is spewing huge amounts of scary error messages to stderr and/or stdout). > FWIW bash seems to do the replacement to U+FFFD itself before it sends > it to the terminal, which means it is (more) predictable. I don't know > if this is a sensible option for ksh. That is not really an option. This matters most while the multibyte character is being typed, when the first byte is already being processed but the second one not yet. Replacing the byte with U+FFFD, then later substituting the actual bytes back when all have arrived, doesn't really make much sense to me. Hanging the shell until all expected bytes have arrived seems like a bad idea, too. You can see the misbehaviour that is causing in programs like uniname(1) from the misc/uniutils package: $ printf '\377turd' | uniname Now the program hangs indefinitely. I wouldn't want the shell to hang in such a manner. Yours, Ingo
