spurious characters to stdout

[Sepp Käsbauer]

Am Montag, 3. März 2008 schrieb 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
>   }
>

Thank you John and Michael for your findings. 

But now i think we are at the core of the problem.
If i run the follwing in a terminal:

echo "sin(3/4*pi)" | octave -q 
ans =  0.70711

everything is perfect. 
But if i redirect the output into a file e.g. i want the result of a 
calculation in batch mode to be saved or be passed thru a pipe to the next 
program then a get the esc-sequence which crashes the following command. 

echo "sin(3/4*pi)" | octave -q > out.dat
vi out.dat
^[[?1034hans =  0.70711


> 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

Sepp