0

when I run command dd if=/dev/random count=1 bs=32 I get some random junk binary data but after receiving them, there is still some characters (as I see always 1;2c) after termination of dd process.

[amirreza@localhost ~]$ dd if=/dev/random count=1 bs=32
¾¿܄ÌYLÔAëEÔr/f&-È<>ýø1+0 records in
1+0 records out
32 bytes copied, 3.5878e-05 s, 892 kB/s
^[[?1;2c[amirreza@localhost ~]$ 1;2c

what is this character and why it's thrown after the termination of dd ?

0
1

This is one of the situations that reveals that a Linux/Unix GUI terminal window is not actually a single integrated thing, but three things working more or less together:

  • the terminal emulator (the actual GUI terminal application, or the built-in terminal emulator of the Linux text console)
  • the TTY or PTY (pseudo-TTY) device driver of the operating system
  • the shell, or whatever program is processing the TTY input at the time.

The random junk happened to contain one of the following byte sequences: 0x1b 0x63 (= ESC c) or 0x1b 0x30 0x63 (ESC0 c).

These sequences have a special meaning for any terminal or terminal emulator that is compatible with the classic VT100 terminal: it requests the terminal(/emulator) to respond with a code that describes the terminal's primary attributes.

The terminal responds with the string ESC[?1:2c, which used to mean "this terminal is a VT100 with an Advanced Video Option". (This is the response xterm and many other terminal emulators compatible with it typically send.)

This string is sent just as if you had typed it, but the dd command does not expect any keyboard and so the PTY driver initially just echoes it back as ^[[?1;2c which you'll see at the beginning of the prompt. (^[ is a common way to represent the ESC control character.)

Then the dd command ends, the shell displays its prompt, sees some input waiting in the PTY driver's input buffer, reads it and tries to interpret it:

  • ESC[ gets interpreted as Meta-[ which is not one of bash's default meta keystrokes so it does nothing.
  • The ? also gets filtered out for some reason I cannot figure out at this time (feel free to comment or edit this answer if you know)
  • the rest is re-displayed by the shell after the prompt, just in case it's the beginning of a command you started typing before the previous command was quite finished.

There are some other control sequences that may affect your terminal emulator too. The list of control sequences understood by Xterm and compatible terminal emulators is available at: https://www.xfree86.org/current/ctlseqs.html

If you accidentally get some random junk to your terminal window and it messes up the terminal display any worse than that (e.g. the random data happens to include a "change character set" code that makes the characters unrecognizable), you may want to learn how to reset a messed-up terminal window back to a sane state. There are several strategies:

  • if you are using a GUI terminal window, it may include a "reset terminal" menu option
  • the control code for "return to the default character set" is a simple Control+o (the letter O, not the number) so you can try typing that and pressing Enter to see if the next prompt looks better.
  • if it looks like you're at the command prompt but the characters are unrecognizable, you can assume it's just a display problem and just blindly type the reset command and press Enter.
  • For any text-based full-screen program (= anything that uses (n)curses), you can press Control+L to request the display to be completely refreshed in case it's messed up in any way.

Not the answer you're looking for? Browse other questions tagged or ask your own question.