note ELISHEVA I wrote a little script to run the test for a variety of codepoints, some you suggested and a few others. Increasingly it is looking like xterm is treating certain byte sequences as some sort of escape seequence. The script let me output in sequence subsets of the following character list: <c>(0x5D0..0x5Df,0xD105,0x21D0)</c> and tagged each output line with the ordinal value of the character being tested so I could be sure of what output line corresponded with what character. What I saw was this: <ul> <li>0x05D1..0x05D7,0x05D9,0x05DC display a single glyph with no ill effects (not a Hebrew letter-but that doesn't matter so much at this point. That is likely a font issue.)</li> <li>0x05D8,0x05DD-0x05DF as well as 0x21D0 cause output to stop in the same way that 0x05D0 does on when xterm is run with wide-char turned off - see above</li> <li>0x05DA seems be treated by the xterm window like an escape sequence: although it outputs everything including the END blocks, it dumps a lot of characters out after the END blocks do their thing and the script terminates. There are characters both before and after the prompt (<c>"myname@debian: "</c>). It looks something like this:<c>^[[?1;2c^[[?1;2cmyname@debian: 1;2c1;2c</c></li> <li>0x05DB replaces the "I" in I'm dying with what looks like a tab</li> <li>0xD105 appears to trigger some sort of vertical tab effect: an accented "i" character is printed followed by what looks like 2 newlines.</li> </ul> Even more interesting is that there are sequencing effects. For instance outputting the three characters <c>0x05D0 0x05D1 0x05D2</c> causes the test for 0x5D0 to stop immediately after outputting 0x05D0 and to resume when 0x5D1 is output by its test. 0x5d2 is printed in full. Similarly, 0x05D0 followed somewhat later by 0x05D2 causes output to be displayed up until 0x05D0 is sent to the terminal and output to resume when 0x05D2 is sent to the terminal. 892034 892050