spurious characters to stdout

[John W. Eaton]

On  3-Mar-2008, Michael Goffioul wrote:

| On 3/3/08, John W. Eaton <jwe at bevo.che.wisc.edu> wrote:
| > | > The original bug report mentioned ASCII chars 30 and 31, not '1' or '0'.
| > | >
| > | > Michael.
| > |
| > | The esc sequence i get is in hex notation:
| > |    1b 5b 3f 31 30 33 34 68
| > | in ascii:
| > |    <esc>[?1034h
| >
| > OK, these are the same if 31 and 30 are hex (== '1' and '0').
| 
| This explains why I couldn't find anything on the "CSI ? 34h"
| control sequence....
| 
| > | The original poster told us:
| > | >  <ESC>[?<US><RS>34h, where <ESC> is ASCII
| > | >  27, <US> is ASCII 31, and <RS> is ASCII 30
| >
| > Ah, the confusion here was that 31 and 30 were decimal, which is US
| > and RS in the ASCII encoding.
| >
| > So, who sends smm to the terminal?  I don't see that it is used
| > anywhere by readline (at least not in an obvious way).
| 
| This control sequence seems to be related to enabling/disabling
| meta-mode in the terminal. This might be sent by readline, when
| enabling meta-key (_rl_enable_meta_key), but I can't check for
| the moment.

OK, I see now.  I was looking at the terminfo codes (smm) while
readline uses the termcap name (mm).  So yes, it is sent by the
function

  void
  _rl_enable_meta_key ()
  {
  #if !defined (__DJGPP__)
    if (term_has_meta && _rl_term_mm)
      tputs (_rl_term_mm, 1, _rl_output_character_function);
  #endif
  }

in readline's terminal.c file.  That your terminal is displaying these
characters instead of interpreting them would seem to indicate that
the termcap/terminfo entry for the terminal does not match the
capability of the terminal itself.  So I think the right fix is to
either fix the terminal so that it understands this sequence, or
disable the km field in the terminfo/termcap entry that encodes the
"has_meta_key" capability, or use a different smm/mm terminfo/termcap
entry that actually matches the terminal you are using.

jwe