Its usually been seen that if an executable is cated, provided that its a huge file, it keeps on changing the title of the 'PuTTYapplication until its done printing the binary to the STDOUT with those weird characters, prefixing strace did not seem to help in knowing.

What all goes on there, which makes this happen? Just curious.

  • 1
    in short, somewhere in the binary is the sequence of bytes that correspond to your terminal's codes for changing the title. cat-ing the binary causes those bytes to be sent to the terminal, which then interprets and acts upon them. cat-ing a binary to a terminal is generally not a good idea. use hd (aka hexdump) or xxd or similar if you want to see what's in a binary (in, e.g., a traditional hexdump format with hex byte offsets and bytes on the LHS and ASCII on the RHS)
    – cas
    Jul 15, 2016 at 1:51

3 Answers 3


As improbable as it might seem, PuTTY does this in response to a combination of characters.

PuTTY recognizes many (by no means all) of the escape sequences used for xterm, Linux console and some less familiar terminals. One of PuTTY's developers compiled a list of all of the ones that might be of interest, about 650 items. You can find copies here and there named "all-escapes.txt", beginning thus:

# This file is hoped to document all the escape sequences supported by
# terminals that are vaguely compliant with ECMA-48 and friends.

# Changes should be submitted to <bjh21@bjh21.me.uk>

# It includes everything from:
# <URL:http://www.cs.utk.edu/~shuford/terminal/dec_vt220_codes.txt> 1999-05-16
# <URL:http://www.cs.utk.edu/~shuford/terminal/vt100_reference_card.txt>
#                                   1993-02-01
# <URL:http://www.cs.utk.edu/~shuford/terminal/vt100_codes_news.txt>1998-09-18
# <URL:http://www.cs.utk.edu/~shuford/terminal/ansi_dec_controls_news.txt>
#                                   1999-05-16
# <URL:http://www.cs.utk.edu/~shuford/terminal/xterm_controls.txt>  1999-10-12
# <URL:http://www.cs.utk.edu/~shuford/terminal/color_control_news.txt>
#                                                                   1999-11-13
# ECMA-48 5th Ed. control functions (section 8.3, annex F)
# Linux console_codes(4)
# SunOS 5.7 wscons(7D)
# UnixWare 7 display(7)
# IRIX 6.5.5 xwsh(1G)
# VT220 Reference manual (<URL:http://vt100.net/docs/vt220-rm/>, EK-VT220-RM)
# <URL:http://vt100.net/ctrlseq_dec.html>                           1999-11-24
# <URL:http://vt100.net/ctrlfunc_dec.html>                          1999-12-01
# <URL:http://www.wyse.com/service/support/kbase/SEQwt.asp?Q=9> (wy75)
#                                                                   1999-07-19
# <URL:ftp://ftp.cs.cmu.edu/afs/cs/user/ralf/pub/rbcom346.zip#TERM-EMU.DOC>
#                                                                   1999-09-13
# <URL:http://www.itscj.ipsj.or.jp/ISO-IR/2-1.htm>                  1999-04-19
# <URL:http://www.itscj.ipsj.or.jp/ISO-IR/2-2.htm>                  2004-09-27
# <URL:http://www.itscj.ipsj.or.jp/ISO-IR/2-3.htm>          2004-09-27
# <URL:http://www.itscj.ipsj.or.jp/ISO-IR/2-8-1.htm>                1999-04-19
# <URL:http://www.itscj.ipsj.or.jp/ISO-IR/2-8-2.htm>                2001-05-10
# iBCS2 description in ESR's termtypes.master version 10.2.7
# Reflection Terminal Reference Manual for ADDS, ANSI, DG, VT, WYSE, and
#       Unisys Hosts; Version 7.0; September 1998; published by WRQ Inc.
# DEC Terminals and Printers Handbook 1985 EB 26291-56 (Appendices C, E, and G)
# OpenServer 5.0.6 screen(HW)
# X Consortium Compound Text Encoding Version 1.1

For whatever reason, they disliked the notion of referring directly to the documentation for Linux and xterm, but used secondary sources.

The title strings recognized by PuTTY begin with one of these choices:

  • ANSI 7-bit OSC (escape]), or
  • ANSI 8-bit OSC (octal 235)

followed by 0, 1, 2, 21 (ASCII digits) or L,

a semicolon,

and the title text,

and end with one of these choices:

  • ANSI 7-bit string terminator (escape\), or
  • ANSI 8-bit string terminator (octal 234), or
  • ASCII BEL (7, used by xterm)

As an aside, it will stop processing the title escape if it sees an ASCII carriage return or line-feed.

While a "big" file might seem to be random enough, it's likely that your file contains some bias in the form of tables, etc. Otherwise it would not repeatedly update the title as described.

It might be interesting to construct a program which detected latent title-strings, so that you could find those without having to reset your terminal (or possibly stop it entirely).

Further reading:

  • 1
    Personally, I would say that the Putty developers were correct in referencing primary documentation such as the VT100 and VT220 documentation rather than Linux documentation
    – fpmurphy
    Jul 14, 2016 at 22:20
  • Terminator is 234 not 233 (which is CSI) Jul 15, 2016 at 9:52
  • Ahem! M. Dickey is fairly authoritative here. Richard Shuford's text files, the very first items listed, are collections of Usenet postings some of which were written by M. Dickey in the first place. Also note that the PuTTY list does indeed reference Linux documentation. console_codes(4) is right there on the list in front of us.
    – JdeBP
    Jul 24, 2016 at 9:04
  • Dave pointed out a typo (I prefer using octal and didn't convert properly). For the other part - my comment should stay. Jul 24, 2016 at 9:16

It doesn't show up separately in strace because it's an in-band control.

Outside PuTTY, this is often noticed as corrupting the prompt. Example: Fix terminal after displaying a binary file

They're called escape sequences - commands expressed as a sequence of characters, which start with the character "escape". clear is a simple example which uses them.

In-band controls can be considered a design flaw; it opens the door to serious problems. https://www.proteansec.com/linux/blast-past-executing-code-terminal-emulators-via-escape-sequences/ (More generally - early automated telephone networks used in-band controls for routing, which allowed control by hackers; see e.g. http://www.mit.edu/hacker/hacker.html).

It may help to remember that the full name for a terminal window is a "terminal emulator". Physical terminals do not really have out-of-band control. Physical serial lines pass streams of bytes (7 or 8 bit).

There's a single serial signal called "break". However the "break condition" is generally only used for one purpose. The way it's described, it sounds like it would take longer to transmit than a normal character.

(The design flaw could be resolved e.g. if non-printable characters were not passed through by default. Emulating a printer without additional controls. Compare inserting a paragraph of text into a HTML template: you need to handle the characters &<> specially to avoid them disappearing and being run as code).

Note physical serial ports have the disadvantage of not communicating the width and height of the terminal :). Physical terminals would be a set size, and I don't think they tended to implement any queries like that. Terminal windows implemented a workaround for this (they send SIGWINCH, which I assume is a signal to check some PTY extension). SSH has some feature that passes this on too. Interestingly the telnet protocol's control for this is described as being in-band. This was done by defining a number of 8-bit codes. It assumes ASCII-only, i.e. is apparently incompatible with UTF-8. Source: How are terminal length and width forwarded over SSH and telnet?


What happens is that your binary happens to contain the escape sequence for setting the window title (in xterms, it's <esc>]2, I don't know if it's different in putty).

  • Putty supports the xterm ANSI codes, you can enable/disable support for some of them in the settings.
    – phk
    Oct 7, 2016 at 13:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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