SOS Start of String

Three control strings carry content meant for someone other than the terminal. Each is closed by ST:

PM is ECMA-48 §8.3.94, p. 53 and APC §8.3.2, p. 33. ECMA-48 lets an SOS string hold any characters but SOS and ST, where PM’s and APC’s, like DCS’s, may hold only printable characters and the format effectors BS to CR. DEC STD 070 reserves SOS for future use, and recommends a terminal treat it as “the start of an unimplemented control string” (§3.5.4.3, p. 3-29). The VT510 manual says that after PM or APC it “ignores all following characters until it receives a SUB, ST, or any other C1 control character”, but lists SOS itself as simply “Ignored”. libghostty-vt treats all three alike, as DEC STD 070 recommends.

None of them is displayed: a string the terminal does not act on is thrown away whole. CAN, SUB, ESC or a C1 control ends one early, as for any control string, so an ESC [ inside an SOS ends the string and starts a control sequence, though ECMA-48 would have it be part of the string.

Terminal emulators have since found uses for APC: kitty’s graphics protocol travels in ESC _ G … ST, which libghostty-vt reads. A terminal that does not know the protocol throws the same bytes away as an APC it does not implement.

All three are C1 controls, with single-byte forms 98, 9E and 9F that libghostty-vt, decoding its input as UTF-8, does not accept.

Validation

SOS-1: None is displayed

A
\eXstart of string\e\\
B
\e^privacy message\e\\
C
\e_application command\e\\
D

|ABCD__|
cursor 1,5
reply none

SOS-2: BEL does not end them

A
\e_hi\a   # BEL is part of the string
B         # and so is this
\e\\
C

|AC____|
bell 0

SOS-3: ESC ends one early

A
\eXa      # an SOS
\e[2;2H   # the ESC ends it, and this is a CUP
b
\e\\      # an ST with nothing to end
B

|A_____|
|_bB___|