1

I'm looking for documented examples of applications using the APC (APPLICATION PROGRAM COMMAND) control character. I've read ECMA-48, which defines it as follows:

APPLICATION PROGRAM COMMAND APC - APPLICATION PROGRAM COMMAND

Notation: (C1)

Representation: 09/15 or ESC 05/15

APC is used as the opening delimiter of a control string for application program use. The command string following may consist of bit combinations in the range 00/08 to 00/13 and 02/00 to 07/14. The control string is closed by the terminating delimiter STRING TERMINATOR (ST). The interpretation of the command string depends on the relevant application program.

I've found that many modern terminal emulator programs recognize this control enough to suppress the display of the APC thru the ST, which seems to match up with the ECMA intent... I'm looking for any examples using "namespaces" that might allow different apps to use different content in the command sequence. I would be particularly interested in examples where a terminal emulator does something with APC sequences.

Example

const APC = "\x9F"
const ST = "\x9C"

console.log(`Hello world${APC}hidden command${ST}!`)

As displayed on the terminal (Windows 10)

PS > node index.js
Hello world!

The "hidden command" is not displayed. This seems good, but if I pipe the output to another app, the command string is in there.

Some shells seem a bit confused by the C1 version of the control characters, I have some work to do to document that.

Background

I'm considering using APC sequences to allow embedded data, e.g., in JSON form, to be mixed into a stdout stream.

Burt_Harris
  • 6,415
  • 2
  • 29
  • 64
  • If you want to use Unicode characters for non-standard use, why not use one from one of the private use areas? They're made for anything that's "implementation dependent". – Joachim Sauer Jun 04 '21 at 21:55
  • I think the private use area is for non-standard graphical characters. The characters I'll put inside the APC will be standard ASCII; JSON Text is all printable. So I assert this will not be non-standard, but compliant with the standard as defined by ECMA (and ANSI) – Burt_Harris Jun 04 '21 at 22:01
  • Private use area codepoints have absolutely no defined semantics by the standard, i.e. the standard also doesn't define them to be glyphs or characters, you can use them as you see fit. Granted, most well-known uses are for various non-Unicode scripts. – Joachim Sauer Jun 04 '21 at 22:06
  • No, I stand by my assertion, offering [UAX #44](http://www.unicode.org/reports/tr44/tr44-4.html) Table 10 as support: Control codes (aka Cc) are by definition limited to the C0 and C1 codes, which aren't really characters. Private-use codes (aka Co) are by definition characters, meaning they are graphical. – Burt_Harris Jun 07 '21 at 18:29
  • Note that 0x9F is not always APC; see https://www.itscj-ipsj.jp/custom_contents/cms/linkfile/ISO-IR.pdf and ISO 2022 (and other standards) in general. – o11c Mar 26 '22 at 23:26

2 Answers2

3

Known users of Application Program Command (APC):

  • Some Kermit implementations (in particular C-Kermit) support running Kermit commands sent as APC strings
  • Kitty uses APC sequences as part of its graphics protocol
  • The Terminal Support Control (TSC) component of the iRMX real-time operating system uses APC sequences. You send a request to the TSC as an OSC and it sends its reply as an APC. (See this PDF, pages numbered 242 and 285, PDF pages 256 and 299)
  • GNU Screen hardstatus is set via APC. (Thanks to Gerrit's answer for finding this.)
  • Similarly, tmux supports using APC to set the window title (see tmux source code input_exit_apc function
  • Perforce (formerly Rogue Wave) HostAccess terminal emulator supports using using APC sequences to build Windows GUIs (see this PDF page 12). This is so you can have a legacy terminal mode application (most commonly business software written in BASIC for the PICK platform) and give it a Windows GUI just by adding escape sequences to the code
  • In the 1980s US military "Integrated Information Support System" (IISS) program, APC sequences were used to send function keys (see ADA182580 PDF page 34, November 1985; ADA249197 PDF page 12, September 1990)
  • Some Beehive terminals supported using APC to send function keys, albeit using an incompatible encoding from IISS. (See for example ATL-008 Technical User's Manual, February 1984, PDF page 45) They also supported using APC (unusually, actually ESC APC, i.e. ESC ESC _) to configure keybindings and the terminal's built-in menu system (see page 104 of that PDF).

You will notice the above are almost all completely incompatible with each other. The only standard for "namespaces" of which I am aware is DEC's internal standard DEC STD 070, which mandates the first character of the APC sequence identify its type/purpose – but DEC themselves never really used APC sequences, and there is no registry of those prefixes. However, Kitty's graphics protocol (approximately) follows that standard by prefixing all its APC messages with G. (I say "approximately", because DEC-STD-070 says only "private use" sequence characters should be used, and apparently G is not one of those.)

The reality is, APC is very rarely implemented – most systems never generate APC sequences and silently ignore any received. No application should send or interpret APC sequences unless it knows the other end of the connection is using them in a particular way – such as through a configuration option to enable their use, or if it (somehow) knows which terminal emulator is being used and knows that terminal emulator assigns them a particular meaning – hence, there isn't much need for "namespaces" in practice. If you really feel the need for "namespaces", probably best option is to use the DEC-STD-070 approach of reserving an initial character.

One of the reasons why APC is rarely used, is it is a potential security vulnerability – if your APC sequence does something potentially harmful, an attacker could put the APC sequence into a file and trick the user into viewing that file using cat/etc. Programs which display untrusted files should filter their output to remove escape sequences such as APC, but programs such as cat generally don't.

Simon Kissane
  • 4,373
  • 3
  • 34
  • 59
  • You have done some excellent research here. Thank you, Simon. DEC STD 070, is by far the most interesting thing you've referenced, at least to me. DEC always did excellent documentation. I'm old enough to remember the switch between VT-52 escapes sequences and VT-100. – Burt_Harris Mar 31 '22 at 15:21
1

Happened to come across this little nugget in the screen manual.

Screen maintains a hardstatus line for every window. 
If a window gets selected, the display's hardstatus
will be updated to match the window's hardstatus line. 
If the display has no hardstatus the line  will  be  displayed
as a standard screen message.
The hardstatus line can be changed with the 
ANSI Application Program Command (APC):
"ESC_<string>ESC\".
As a convenience for xterm users the sequence
"ESC]0..2;<string>^G" is also accepted.
Gerrit
  • 861
  • 6
  • 11