I have experienced similar behaviour before, but only now I can reproduce it: Output from a command affecting the text after the next command prompt, ready to be Entered by the user.

Take the following example:

cat /usr/share/terminfo/a/ansi

which has the following effect:

enter image description here

Or, copied and pasted:

1%t;7%;%?%p2%t;4%;%?%p3%t;7%;%?%p4%t;5%;%?%p6%t;1%;%?%p7%t;8%;%?%p9%t;11%;m +%d;%dR;0123456789]c1%dm1%dmAX[user@untrusted ~]$ R65;1;9c

As you can see, R65;1;9c appears after the command prompt and pressing Enter will have it evaluated as command.

I do remember cases where text not only appeared after the command line, but was also executed again, possibly due to it containing newlines.

Can this be considered bug or is this anticipated behaviour, that some kind of combination of non-printable characters allows writing after the next command prompt?

  • 2
    Maybe the binary data you send to the terminal happens to contain a control sequence that manipulates the terminal's input buffer. Maybe related to unix.stackexchange.com/q/213799/330217
    – Bodo
    Commented Sep 18, 2020 at 11:24

1 Answer 1


What you are seeing is the attribute string for the terminal. Terminals might respond differently to one or more of these commands.

A quick way to reproduce them:

$ echo -e '\033[c'

In my case, inside Gnome terminal this types 65;1;9c, inside xterm it types 64;1;2;6;9;15;18;21;22c and in the console, after pressing Ctrl-Alt-F1 I get 6c.

The strings are created by the terminal, so you cannot use them to "insert" arbitrary text.

This page tells you more about their meaning:

   CSI Ps c  Send Device Attributes (Primary DA).
          Ps = 0  or omitted -> request attributes from terminal.  The
          response depends on the decTerminalID resource setting.
            -> CSI ? 1 ; 2 c  ("VT100 with Advanced Video Option")
            -> CSI ? 1 ; 0 c  ("VT101 with No Options")
            -> CSI ? 6 c  ("VT102")
            -> CSI ? 6 2 ; Psc  ("VT220")
            -> CSI ? 6 3 ; Psc  ("VT320")
            -> CSI ? 6 4 ; Psc  ("VT420")
          The VT100-style response parameters do not mean anything by
          themselves.  VT220 (and higher) parameters do, telling the
          host what features the terminal supports:
            Ps = 1  -> 132-columns.
            Ps = 2  -> Printer.
            Ps = 3  -> ReGIS graphics.
            Ps = 4  -> Sixel graphics.
            Ps = 6  -> Selective erase.
            Ps = 8  -> User-defined keys.
            Ps = 9  -> National Replacement Character sets.
            Ps = 1 5  -> Technical characters.
            Ps = 1 8  -> User windows.
            Ps = 2 1  -> Horizontal scrolling.
            Ps = 2 2  -> ANSI color, e.g., VT525.
            Ps = 2 9  -> ANSI text locator (i.e., DEC Locator mode).

Some devices will also output identifying information for the device (Request terminal parameters) with the following escape sequence.

$ echo -e '\033[x'
  • Thanks! Some further context: \033[c (or <ESC>[c) is an ANSI/VT100 control sequence initiated by <ESC>[. It's defined in ECMA-48 as DEVICE ATTRIBUTES with a hex representation of \x63, an ASCII c. An older reference refers to it by Query Device Code. Also see man console_codes and the VT100 User Guide.
    – Quasimodo
    Commented Sep 22, 2020 at 23:17
  • Strangely however, echo -e '\033[c' does result in 65;1;9c for my GNOME terminal (without the R above).
    – Quasimodo
    Commented Sep 23, 2020 at 0:53
  • Besides primary device attributes, XTerm also supports requesting secondary and tertiary DAs, e.g. echo -e '\e[>c' or echo -e '\e[=c'. They are documented at the page XTerm Control Sequences.
    – Quasimodo
    Commented Sep 23, 2020 at 20:35

You must log in to answer this question.

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