enter image description here Notice the nonexistent space displayed in the first output. I've sent this to Apple as a bug, but is there anything the user (or admin) can do to fix it? Locale is en_US.UTF-8

The worst part of the bug is that it screws up command-recall-and-edit. Any non-ASCII character in the command has a bogus space displayed after it. But the space is counted when the cursor passes it, resulting in the edit position not being where the cursor is.

If I copy a line with such a bogus space and paste it in TextEdit, the space goes away. So I don't think it's a bug in the shell. Also, it happened in both bash and zsh.

  • Maybe a bug in the shell and not t
    – WGroleau
    Sep 22 at 2:54
  • What font is this supposed to be? Please don't paste pictures of text. Sep 22 at 4:27
  • Can you run ls -d All* | tr ' ' '.'; ls -dB All* and copy/paste the result (as text)?
    – nohillside
    Sep 22 at 5:22
  • Also, which text encoding is set in the profile you use in Terminal?
    – nohillside
    Sep 22 at 5:38
  • The text encoding is also set to UTF-8. It does this with any font, but that one is Andale. Pasting the text will not help—if I paste it elsewhere, it is rendered correctly.
    – WGroleau
    Sep 22 at 6:13

"nohillside" asked which encoding I had in the preferences. That was not the problem, but it showed me part of the problem.

Immediately below that preference is a checkbox for “Unicode East Asian Ambiguous characters are wide.” That label is misleading—if checked, all non-ASCII characters are wide (not merely East Asian Ambiguous).

The other part of the problem is that "wide" means that it adds a space to the output and the edit cursor movements count characters displayed while the edit position counts the actual characters.

I turned off that option (which I actually see no value in) and the bogus spaces are gone.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .