Origins Of Control Characters

[Lawrence D'Oliveiro]

Who was the first to use ASCII control characters for line-editing and in-
band signalling purposes on terminals connected to interactive timesharing
systems? Was it DEC?

Consider things like:
CTRL/C -- interrupt the currently-running program
CTRL/O -- discard all subsequent program output until the next read

Line-editing:
DEL -- delete the last character typed
CTRL/U -- clear the entire partially-entered line
CTRL/R -- redisplay what has been typed so far

(Note that DEL is ASCII 127 aka RUBOUT, not ASCII 8 which is CTRL/H or
backspace.)

All the above were on DEC systems, and are available on current *nix
systems.

(On very early Bell Labs Unix, they might have used printable characters
for some of these functions; e.g. I vaguely recall an article mentioning
“#” as the delete character. I suspect this convention was rendered
obolete by the more modern one very quickly.)

From this point, things start to diverge a bit. Consider the EOF
indication: the character you type to indicate there is no more when a
program is reading data from the terminal: DEC had this as CTRL/Z, but
*nix systems somehow decided to use CTRL/D instead.

DEC added CTRL/X on VMS to mean “cancel all type-ahead” -- that is,
everything that has been typed so far, that the program has not read. This
function doesn’t exist on *nix.

Then there was the introduction of a second interrupt key, I guess as a
kind of a backstop to interrupt programs that had trapped the first one
and then got stuck: DEC decided upon CTRL/Y for this on VMS, while *nix
went for CTRL/backslash. (On some earlier DEC systems, in theory if you
could hit CTRL/C a second time quickly enough, it would force-abort a
program that had trapped CTRL/C. But I never found a way to type an
effective double-CTRL/C sequence without hardware help.)

DEC also had the handy CTRL/T sequence to generate a one-line display of
what a running program was up to: *nix systems never adopted this.

What *nix systems did have, that DEC did not, was the use of CTRL/V to say
“quote the next character”. This let you enter literal CTRL/C and the
other control characters (including CTRL/V itself, of course) as part of
data input.

[Rich Alderson]

Post by Lawrence D'Oliveiro
DEC also had the handy CTRL/T sequence to generate a one-line display of
what a running program was up to: *nix systems never adopted this.

You should look at tcsh, the TENEX C shell, a Berkeley innovation which did
include ^T as a status update character.

NB: My name appeared in the man page for tcsh at one point, based on things I
had written in this very newsgroup back in the late 1980s. Depending on where
you get the man page, it still shows up.

Post by Lawrence D'Oliveiro
What *nix systems did have, that DEC did not, was the use of CTRL/V to say
"quote the next character". This let you enter literal CTRL/C and the other
control characters (including CTRL/V itself, of course) as part of data
input.

That's funny. One fo the first hacks I learned on TOPS-20--a DEC operating
system--was to use ^V to quote special characters in file names. Very popular
was the sequence ^V<ESC>, which looked in the directory listing as if it were a
"$".

Note that ^V was also used in the MIT based Lisp Machines as a quote, where it
echoed as a crosshatched circle (the outer product symbol) in directory listings.

If you're going to write this stuff, do try to get it right.

[Lawrence D'Oliveiro]

Post by Rich Alderson

Post by Lawrence D'Oliveiro
DEC also had the handy CTRL/T sequence to generate a one-line display
of what a running program was up to: *nix systems never adopted this.

You should look at tcsh, the TENEX C shell, a Berkeley innovation which
did include ^T as a status update character.

That would have come from DEC’s earlier TOPS-10.

Post by Rich Alderson
If you're going to write this stuff, do try to get it right.

You were doing so well, until you got to this bit. 💩

[Mike Spencer]

NB: My name appeared in the man page for tcsh at one point, based on
things I had written in this very newsgroup back in the late 1980s.
Depending on where you get the man page, it still shows up.

Yup, there you are [Slackware Linux 15.0]:

THANKS TO

[snip]
Richard M. Alderson III, for writing the `T in tcsh' section

Astron 6.23.02 3 Jan 2022 TCSH(1)

[Ahem A Rivet's Shot]

On 21 May 2024 01:59:54 -0300

NB: My name appeared in the man page for tcsh at one point, based on
things I had written in this very newsgroup back in the late 1980s.
Depending on where you get the man page, it still shows up.

Also in FreeBSD.

[Alex Martini]

Post by Lawrence D'Oliveiro
DEC also had the handy CTRL/T sequence to generate a one-line display of
what a running program was up to: *nix systems never adopted this.

Unix systems have this -- but you're only going to see it in a program
that uses "cooked" mode input. If you run ed or cat or sed and press
control-T when it's waiting for input, you'll see a line like this:

load: 3.37 cmd: ed 93828 waiting 0.00u 0.00s

You can see the full set of active control characters that are supported
in cooked mode input by running "stty -a". (If memory serves, cooked
mode means the kernel itself implements the text-editing commands for
input.)

A majority of common commands these days use "raw" mode input so they
can offer line editing and history, which I suspect is often why folks
often aren't aware of how cooked mode works.

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro
DEC also had the handy CTRL/T sequence to generate a one-line display
of what a running program was up to: *nix systems never adopted this.

Unix systems have this ...

Which ones? Linux doesn’t.

[Ike Naar]

Post by Lawrence D'Oliveiro

Post by Lawrence D'Oliveiro
DEC also had the handy CTRL/T sequence to generate a one-line display
of what a running program was up to: *nix systems never adopted this.

Unix systems have this ...

Which ones? Linux doesn’t.

NetBSD has it.

[Lawrence D'Oliveiro]

Post by Ike Naar

Post by Lawrence D'Oliveiro

Post by Lawrence D'Oliveiro
DEC also had the handy CTRL/T sequence to generate a one-line display
of what a running program was up to: *nix systems never adopted this.

Unix systems have this ...

Which ones? Linux doesn’t.

NetBSD has it.

Another one specific to one or the other of the BSDs, that Linux doesn’t
have, is I believe the use of CTRL/Y to combine the effect of CTRL/Z (stop
foreground job) followed by “bg” to resume the job in the background.

I didn’t mention CTRL/Z for *nix job control, did I?

[Lawrence D'Oliveiro]

Post by Alex Martini
If you run ed or cat or sed and press

Is that done by being hard-coded in the terminal driver, like early DEC
systems? Or is it done as part of a more general mechanism, like in VMS?

In some ways I would like to see a VMS-style terminal driver on a *nix
system. But it’s hard to see how to reconcile the QIO model of separate
request packets with simple character devices that read and write streams
of bytes.

[Ahem A Rivet's Shot]

On Sun, 19 May 2024 08:58:16 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by Alex Martini
If you run ed or cat or sed and press

Is that done by being hard-coded in the terminal driver, like early DEC
systems? Or is it done as part of a more general mechanism, like in VMS?

It's part of the stty mechanism which is a generalised version of
the hard coded terminal driver code dating back to Version 2 unix and
covers things like intercepting control characters, echo, flow control,
parity and end of line handling all of which can be altered on the fly
while using the terminal they affect (blind typing stty sane<Ctrl-J> is a
useful skill if you play with these).

[Lawrence D'Oliveiro]

Post by Ahem A Rivet's Shot
On Sun, 19 May 2024 08:58:16 -0000 (UTC)

Post by Lawrence D'Oliveiro

If you run ed or cat or sed and press control-T when it's waiting for

Is that done by being hard-coded in the terminal driver, like early DEC
systems? Or is it done as part of a more general mechanism, like in VMS?

It's part of the stty mechanism ...

So it’s hard-coded. Not like, say, the more generic “out-of-band AST”
mechanism in the VMS terminal driver.

[Ahem A Rivet's Shot]

On Sun, 19 May 2024 23:50:35 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by Ahem A Rivet's Shot
On Sun, 19 May 2024 08:58:16 -0000 (UTC)

Post by Lawrence D'Oliveiro

If you run ed or cat or sed and press control-T when it's waiting for

Is that done by being hard-coded in the terminal driver, like early DEC
systems? Or is it done as part of a more general mechanism, like in VMS?

It's part of the stty mechanism ...

So it’s hard-coded. Not like, say, the more generic “out-of-band AST”
mechanism in the VMS terminal driver.

No it's configurable.

[Lawrence D'Oliveiro]

On Sun, 19 May 2024 23:50:35 -0000 (UTC) Lawrence D'Oliveiro

Post by Lawrence D'Oliveiro

On Sun, 19 May 2024 08:58:16 -0000 (UTC) Lawrence D'Oliveiro

Post by Lawrence D'Oliveiro

If you run ed or cat or sed and press control-T when it's waiting

Is that done by being hard-coded in the terminal driver, like early
DEC systems? Or is it done as part of a more general mechanism, like
in VMS?

It's part of the stty mechanism ...

So it’s hard-coded. Not like, say, the more generic “out-of-band AST”
mechanism in the VMS terminal driver.

No it's configurable.

Can you specify different characters to send different notifications to a
process?

[Ahem A Rivet's Shot]

On Mon, 20 May 2024 08:00:10 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by Ahem A Rivet's Shot
No it's configurable.

Can you specify different characters to send different notifications to a
process?

Yes eg:

✓ ***@steve ~ $ stty -a
speed 38400 baud; 24 rows; 80 columns;
lflags: icanon isig iexten echo echoe echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
brkint -inpck -ignpar -parmrk iutf8
oflags: opost onlcr -ocrnl tab0 -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf rtsdtr
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;

So among other things ^S will send SIGSTOP

✓ ***@steve ~ $ stty stop ^K
✓ ***@steve ~ $ stty -a
speed 38400 baud; 24 rows; 80 columns;
lflags: icanon isig iexten echo echoe echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
brkint -inpck -ignpar -parmrk iutf8
oflags: opost onlcr -ocrnl tab0 -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf rtsdtr
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
status = ^T; stop = ^K; susp = ^Z; time = 0; werase = ^W;

Now it's ^K that sends SIGSTOP.

[vallor]

On Mon, 20 May 2024 10:31:50 +0100, Ahem A Rivet's Shot

Post by Ahem A Rivet's Shot
On Mon, 20 May 2024 08:00:10 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by Ahem A Rivet's Shot
No it's configurable.

Can you specify different characters to send different notifications to a
process?

speed 38400 baud; 24 rows; 80 columns;
lflags: icanon isig iexten echo echoe echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
brkint -inpck -ignpar -parmrk iutf8
oflags: opost onlcr -ocrnl tab0 -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf rtsdtr
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;
So among other things ^S will send SIGSTOP
speed 38400 baud; 24 rows; 80 columns;
lflags: icanon isig iexten echo echoe echok echoke -echonl echoctl
-echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
-extproc
iflags: -istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk
brkint -inpck -ignpar -parmrk iutf8
oflags: opost onlcr -ocrnl tab0 -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf rtsdtr
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
status = ^T; stop = ^K; susp = ^Z; time = 0; werase = ^W;
Now it's ^K that sends SIGSTOP.

I may be wrong, but I think the ^S/^X are just xoff/xon to
stop and start tty output.

If I'm not wrong, ^Z will cause a SIGSTOP and give you a
shell prompt, though.

[Vir Campestris]

Post by vallor
I may be wrong, but I think the ^S/^X are just xoff/xon to
stop and start tty output.

^S/^Q are stop and start, xoff xon.

Post by vallor
If I'm not wrong, ^Z will cause a SIGSTOP and give you a
shell prompt, though.

Andy

[Lawrence D'Oliveiro]

Post by Ahem A Rivet's Shot
On Mon, 20 May 2024 08:00:10 -0000 (UTC)

Post by Lawrence D'Oliveiro

Post by Ahem A Rivet's Shot
No it's configurable.

Can you specify different characters to send different notifications to
a process?

So among other things ^S will send SIGSTOP

That’s not what I meant. Any *nix system lets you configure the
characters used to send those predefined signals. I meant a mechanism
to send custom notifications to processes, that they can take any
action on that they like.

See the IO$_SETMODE-with-IO$M_OUTBAND function here
<http://odl.sysworks.biz/disk$vaxdocdec022/opsys/vmsos73/vmsos73/6136/6136pro_020.html>.

[Ahem A Rivet's Shot]

On Mon, 20 May 2024 22:46:52 -0000 (UTC)

Post by Lawrence D'Oliveiro
That’s not what I meant. Any *nix system lets you configure the
characters used to send those predefined signals. I meant a mechanism
to send custom notifications to processes, that they can take any
action on that they like.

Ah then no.

[Scott Lurndal]

Post by Ahem A Rivet's Shot
On Mon, 20 May 2024 22:46:52 -0000 (UTC)

That’s not what I meant. Any *nix system lets you configure the
characters used to send those predefined signals. I meant a mechanism
to send custom notifications to processes, that they can take any
action on that they like.

Ah then no.

$ man msgsnd

[Lawrence D'Oliveiro]

Post by Scott Lurndal
$ man msgsnd

To make it clearer what I mean, see the IO$_SETMODE-with-IO$M_OUTBAND
function here
<http://odl.sysworks.biz/disk$vaxdocdec022/opsys/vmsos73/vmsos73/6136/6136pro_020.html>.

[Scott Lurndal]

Post by Lawrence D'Oliveiro

Post by Scott Lurndal
$ man msgsnd

To make it clearer what I mean, see the IO$_SETMODE-with-IO$M_OUTBAND
function here
<http://odl.sysworks.biz/disk$vaxdocdec022/opsys/vmsos73/vmsos73/6136/6136pro_020.html>.

Unix doesn't have the VMS asynchronous system trap concept per-se.

However an unix application is free to put the tty into raw mode and
interpret all the control characters however it pleases, including
associating them with specific user-defined signals (SIGUSR{12} or
the set of real-time signals).

[Lawrence D'Oliveiro]

Post by Scott Lurndal
Unix doesn't have the VMS asynchronous system trap concept per-se.

There is a POSIX equivalent, in the form of “real-time signals”.

[Scott Lurndal]

Post by Scott Lurndal
Unix doesn't have the VMS asynchronous system trap concept per-se.

There is a POSIX equivalent, in the form of “real-time signals”.

While real time signals (mentioned in the part you snipped) have some
similarities to AST's, they're not necessarily equivalent to ASTs which
are baked into most VMS APIs (e.g. QIO/QIOW, Event Flags, RMS et alia).

[Lawrence D'Oliveiro]

Post by Scott Lurndal

Post by Lawrence D'Oliveiro

Post by Scott Lurndal
Unix doesn't have the VMS asynchronous system trap concept per-se.

There is a POSIX equivalent, in the form of “real-time signals”.

While real time signals (mentioned in the part you snipped) have some
similarities to AST's, they're not necessarily equivalent to ASTs which
are baked into most VMS APIs (e.g. QIO/QIOW, Event Flags, RMS et alia).

Nevertheless, they can be used to deliver similar asynchronous
notifications.

[Charlie Gibbs]

Post by Lawrence D'Oliveiro
Can you specify different characters to send different notifications to a
process?

Not that I know of, but IIRC the Amiga did. Perhaps they were control-C,
-D, -E, and -F. But those brain cells are a bit faded...

[Lawrence D'Oliveiro]

Post by Charlie Gibbs

Post by Lawrence D'Oliveiro
Can you specify different characters to send different notifications to a
process?

Not that I know of, but IIRC the Amiga did. Perhaps they were control-

C,

Post by Charlie Gibbs
-D, -E, and -F. But those brain cells are a bit faded...

Remember, I’m not talking about assigning different keys to preexisting
interrupt signals: I’m talking about sending entirely custom notifications
to a process.

[John Levine]

Post by Lawrence D'Oliveiro
Remember, I’m not talking about assigning different keys to preexisting
interrupt signals: I’m talking about sending entirely custom notifications
to a process.

The various control characters send signals. A process can catch the
signal and do whatever it wants. I suppose you could come up with
something more complicated but this seems to have done the trick for
the past several decades.

For example the ^T character normally prints a status line but it also
sends a SIGINFO. Some commands catch that and print more informative
stuff, e.g. on FreeBSD:

$ sleep 10
load: 2.19 cmd: sleep 72398 [nanslp] 3.12r 0.00u 0.00s 0% 1920k
mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_timedwait_sig+0x12 _sleep+0x1bc kern_clock_nanosleep+0x1d1 sys_nanosleep+0x3b amd64_syscall+0x10c fast_syscall_common+0xf8
sleep: about 6 second(s) left out of the original 10

The first two lines are the default message, the third is what sleep does with SIGINFO.

[Lawrence D'Oliveiro]

Post by John Levine
For example the ^T character normally prints a status line but it also
sends a SIGINFO.

Seems like SIGINFO is also mentioned in Linux, as a synonym for SIGPWR.

Not sure I want a power-fail notification sent every time the user presses
a harmless key ...

But remember, I’m not talking about assigning keys to preexisting
interrupt signals: I’m talking about sending entirely custom
notifications to a process.

[John Levine]

Post by Lawrence D'Oliveiro

Post by John Levine
For example the ^T character normally prints a status line but it also
sends a SIGINFO.

Seems like SIGINFO is also mentioned in Linux, as a synonym for SIGPWR.
Not sure I want a power-fail notification sent every time the user presses
a harmless key ...

If you keep reading the man page you will see that SIGPWR is ignored
by default. Its a historical wart. The machines that actually do
something about power failures are more likely to have a connection
from the UPS which tells it to shut down like the "poweroff" comand.

Post by Lawrence D'Oliveiro
But remember, I’m not talking about assigning keys to preexisting
interrupt signals: I’m talking about sending entirely custom
notifications to a process.

I have no idea what "custom notfications" means but Unix presumably
doesn't have it. If it were useful I expect someone would have
implemented it sometime in the past decades.

Also keep in mind that only us troglodytes care about tty input. These
days normal people do everything through a GUI of which Unix and Linux
have many, with vast numbers of features and options.

[Lawrence D'Oliveiro]

I have no idea what "custom notfications" means ...

See the IO$_SETMODE-with-IO$M_OUTBAND function here
<http://odl.sysworks.biz/disk$vaxdocdec022/opsys/vmsos73/vmsos73/6136/6136pro_020.html>.

[Vir Campestris]

Post by Lawrence D'Oliveiro
Who was the first to use ASCII control characters for line-editing and in-
band signalling purposes on terminals connected to interactive timesharing
systems? Was it DEC?
CTRL/C -- interrupt the currently-running program
CTRL/O -- discard all subsequent program output until the next read
DEL -- delete the last character typed
CTRL/U -- clear the entire partially-entered line
CTRL/R -- redisplay what has been typed so far
(Note that DEL is ASCII 127 aka RUBOUT, not ASCII 8 which is CTRL/H or
backspace.)

<snip>

Way back when I was young paper tape was a common way of putting data
into a system. It had ASCII codes on it, but one of the problems was
that you can't rub anything out.

Except.

The tape was 7 bits wide, and if you punch out all the holes it deletes
the character that was there.

That's the DEL character.

Andy

[Bob Eager]

Post by Vir Campestris

Post by Lawrence D'Oliveiro
Who was the first to use ASCII control characters for line-editing and in-
band signalling purposes on terminals connected to interactive
timesharing systems? Was it DEC?
CTRL/C -- interrupt the currently-running program CTRL/O --
discard all subsequent program output until the next read
DEL -- delete the last character typed CTRL/U -- clear the entire
partially-entered line CTRL/R -- redisplay what has been typed so
far
(Note that DEL is ASCII 127 aka RUBOUT, not ASCII 8 which is CTRL/H or
backspace.)

<snip>
Way back when I was young paper tape was a common way of putting data
into a system. It had ASCII codes on it, but one of the problems was
that you can't rub anything out.
Except.
The tape was 7 bits wide, and if you punch out all the holes it deletes
the character that was there.
That's the DEL character.

Well, 8 bits wide, usually a parity bit although that track was usually
blank (although I did use one system that insisted on it being always
punched).

I also used 5 track tape, which did the same.

[Andy Walker]

Post by Bob Eager

Post by Vir Campestris
The tape was 7 bits wide, and if you punch out all the holes it deletes
the character that was there.
That's the DEL character.

Well, 8 bits wide, usually a parity bit although that track was usually
blank (although I did use one system that insisted on it being always
punched).

Mid-60s, our Flexowriters used 7-track tape inc a parity bit.
Every character had to have odd parity, so blank tape was verboten.
So there were effectively 64 possible characters, comprising DEL, two
shift keys and [therefore] up to 61x2 == 122 "useful" codes. With
overstrikes and "line reconstruction", we had a very rich character
set and it was a wrench moving to later computers with a mere 8 bits
per character.

[Lawrence D'Oliveiro]

Post by Bob Eager
I also used 5 track tape, which did the same.

5-track tape used Baudot code. And according to the charts here
<https://en.wikipedia.org/wiki/Baudot_code>, all holes punched was a
printing character.

[Charlie Gibbs]

Post by Lawrence D'Oliveiro

Post by Bob Eager
I also used 5 track tape, which did the same.

5-track tape used Baudot code. And according to the charts here
<https://en.wikipedia.org/wiki/Baudot_code>, all holes punched was a
printing character.

I looked at that page, and it's a bit confusing. To put it in simpler
terms, all 5 channels punched is a "letters shift" code. If the
printer is in figures shift (used to print numerals and special
characters), this code shifts it back down into letters shift.
If the printer is already in letters shift, it's basically a no-op.
Throwing in extra letters shift codes from time to time guarantes
that you aren't trying to interpret text in figures shift; some
Teletypes had an option to unshift on space, to minimize the
confusion if a line hit garbled a character into a figures shift.

All holes punched made as good a leader on Baudot machines as it
did on ASCII machines.

[Lawrence D'Oliveiro]

Post by Charlie Gibbs
I looked at that page, and it's a bit confusing.

Baudot code can be a bit confusing, because with just 32 different codes,
it was trying to allow for printing at least 52 different characters. Also
there were different variations on the same basic idea over time.

Looking at the various charts:

* The code with no holes punched represents a blank.
* There are 27 (26 in some versions?) codes for (nonblank) printing
characters. Each one can produce two different characters, depending on
whether “letter shift” or “figure shift” mode is in effect.
* There are two control codes called “letter shift” and “figure shift”,
for switching modes. “Letter shift” is so-called because most/all of the
printing codes produce letters in this mode.
* There are two more separate control codes for CR and LF.

Some versions have a code called “erasure”. Does it mean “delete previous
character”? Might do. Notice it does not have all the holes punched.

On the Creed machines in the newsroom where my father worked, I remember
there was a “bell” code (which made the noise and also printed a bell
character). Some operators even used that for representing quotation
marks; others might use the “£” sign. Nobody used the actual quotation
mark.

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro
5-track tape used Baudot code.

Baudot is also the guy whose name gives us the term “baud”, the unit for
measuring “signal transitions per second”. Which some people mistakenly
take to mean “bits per second”.

[Scott Lurndal]

Post by Bob Eager

Post by Vir Campestris

Post by Lawrence D'Oliveiro
Who was the first to use ASCII control characters for line-editing and in-
band signalling purposes on terminals connected to interactive
timesharing systems? Was it DEC?
CTRL/C -- interrupt the currently-running program CTRL/O --
discard all subsequent program output until the next read
DEL -- delete the last character typed CTRL/U -- clear the entire
partially-entered line CTRL/R -- redisplay what has been typed so
far
(Note that DEL is ASCII 127 aka RUBOUT, not ASCII 8 which is CTRL/H or
backspace.)

<snip>
Way back when I was young paper tape was a common way of putting data
into a system. It had ASCII codes on it, but one of the problems was
that you can't rub anything out.
Except.
The tape was 7 bits wide, and if you punch out all the holes it deletes
the character that was there.
That's the DEL character.

Well, 8 bits wide, usually a parity bit although that track was usually
blank (although I did use one system that insisted on it being always
punched).

PDP-8, since ASCII characters had bit 7 set (e.g. space was 0240 (octal)).

[Bob Eager]

Post by Scott Lurndal

Post by Bob Eager

Post by Vir Campestris

Post by Lawrence D'Oliveiro
Who was the first to use ASCII control characters for line-editing and in-
band signalling purposes on terminals connected to interactive
timesharing systems? Was it DEC?
CTRL/C -- interrupt the currently-running program CTRL/O --
discard all subsequent program output until the next read
DEL -- delete the last character typed CTRL/U -- clear the
entire partially-entered line CTRL/R -- redisplay what has been
typed so far
(Note that DEL is ASCII 127 aka RUBOUT, not ASCII 8 which is CTRL/H
or backspace.)

<snip>
Way back when I was young paper tape was a common way of putting data
into a system. It had ASCII codes on it, but one of the problems was
that you can't rub anything out.
Except.
The tape was 7 bits wide, and if you punch out all the holes it
deletes the character that was there.
That's the DEL character.

Well, 8 bits wide, usually a parity bit although that track was usually
blank (although I did use one system that insisted on it being always
punched).

PDP-8, since ASCII characters had bit 7 set (e.g. space was 0240 (octal)).

The one I had in mind was a Honeywell DDP-516

[Vir Campestris]

Post by Bob Eager

Post by Vir Campestris
Way back when I was young paper tape was a common way of putting data
into a system. It had ASCII codes on it, but one of the problems was
that you can't rub anything out.
Except.
The tape was 7 bits wide, and if you punch out all the holes it deletes
the character that was there.
That's the DEL character.

Well, 8 bits wide, usually a parity bit although that track was usually
blank (although I did use one system that insisted on it being always
punched).
I also used 5 track tape, which did the same.

Way back when I was young is a long time ago, and I don't think I've
touched paper tape since the 80s.

Thank you for the correction. I'd forgotten about the parity bit!

Andy

[Lawrence D'Oliveiro]

Post by Vir Campestris
That's the DEL character.

That’s right. But remember, the point of using this on paper tape was so
it could be ignored by most reader software.

Its use on a terminal to mean “forget the previous character” is a logical
evolution of this, but still a little bit different.

[Lawrence D'Oliveiro]

When Gary Kildall was working on CP/M, he started out cross-compiling it
on a DEC PDP-10 running TOPS-10, I believe. This would be where he picked
up a number of DEC influences in his new OS, including the use of CTRL/C
for the interrupt key, and CTRL/Z for end-of-file.

However, CTRL/C was only detected by polling every time the program made
an OS call. So if it went for long periods without make such a call, then
your system would still hang.

CTRL/Z was even used in text files to mark the useful end of the text.
This was because the early CP/M filesystem only allocated file space in
units of whole blocks; it was up to the application to keep track of how
the space in those blocks was used internally.

Microsoft copied both these CTRL/C and CTRL/Z conventions into MS-DOS.
Though with Windows, the support for CTRL/C somehow went away.

[Charlie Gibbs]

Post by Lawrence D'Oliveiro
Microsoft copied both these CTRL/C and CTRL/Z conventions into MS-DOS.

The control-Z EOF character was never necessary in MS-DOS, since
its file system stores the size of a file to the byte. Retention
of a control-Z EOF marker is one of the many bad decisions Microsoft
has inflicted on an unsuspecting industry, and has led to all sorts
of data loss. In fact, an early version of MS-DOS (circa 3.1)
contained a bug where output redirected to append to a file
(e.g. dir >>foo) would not erase a hex 1A if one was already
present at the end of the file, but would append the new data
after it. This meant that the new data would be present, but
not readable. They fixed that one pretty quickly.

Post by Lawrence D'Oliveiro
Though with Windows, the support for CTRL/C somehow went away.

It still works in some places.

[Lawrence D'Oliveiro]

Post by Lawrence D'Oliveiro
Microsoft copied both these CTRL/C and CTRL/Z conventions into MS-DOS.

The control-Z EOF character was never necessary in MS-DOS, since its
file system stores the size of a file to the byte.

That was only true in MS-DOS 2.0 and later. In 1.x, file allocation was
just as simplistic as in CP/M.

MS-DOS 2 introduced a bunch of Unix-like features like byte-level file
allocation and piping and redirection in COMMAND.COM (all done with
temporary files, no actual pipes or separate processes for you).

Post by Lawrence D'Oliveiro
Though with Windows, the support for CTRL/C somehow went away.

It still works in some places.

You’d think it would work in the terminal window. But it doesn’t, as far
as I know--not with the interrupt function, anyway.

[Rich Alderson]

Post by Lawrence D'Oliveiro
When Gary Kildall was working on CP/M, he started out cross-compiling it
on a DEC PDP-10 running TOPS-10, I believe. This would be where he picked
up a number of DEC influences in his new OS, including the use of CTRL/C
for the interrupt key, and CTRL/Z for end-of-file.

Kildall worked on DOS-11 as an engineer before starting his own company. He
didn't get ^C/^Z from the -10.

[Lawrence D'Oliveiro]

Post by Rich Alderson

Post by Lawrence D'Oliveiro
When Gary Kildall was working on CP/M, he started out cross-compiling
it on a DEC PDP-10 running TOPS-10, I believe. This would be where he
picked up a number of DEC influences in his new OS, including the use
of CTRL/C for the interrupt key, and CTRL/Z for end-of-file.

Kildall worked on DOS-11 as an engineer before starting his own company.
He didn't get ^C/^Z from the -10.

Can’t find any reference for him ever working at DEC.

[Alan Bowler]

Post by Lawrence D'Oliveiro
(On very early Bell Labs Unix, they might have used printable characters
for some of these functions; e.g. I vaguely recall an article mentioning
“#” as the delete character. I suspect this convention was rendered
obsolete by the more modern one very quickly.)

I expect it was "@" not "#", since that was what was used on the
Honeywell GCOS (GE GECOS) system that Bell Labs used at the time.
Since most of the timeshared terminals at the time were hardcopy,
backspace did not make sense since that would leave an unreadable
smudge if you backspaced and overtyped with the characters you actually
wanted. With the @ you could at at least count what was on the paper
and see if you got the right count and the corrected characters.
With GCOS line editing is done in a front end processor, only
the edited line is transmitted to the mainframe AFTER carriage
return is hit.

[Bob Eager]

Post by Lawrence D'Oliveiro
(On very early Bell Labs Unix, they might have used printable
characters for some of these functions; e.g. I vaguely recall an
article mentioning “#” as the delete character. I suspect this
convention was rendered obsolete by the more modern one very quickly.)

Honeywell GCOS (GE GECOS) system that Bell Labs used at the time. Since
most of the timeshared terminals at the time were hardcopy, backspace
did not make sense since that would leave an unreadable smudge if you
backspaced and overtyped with the characters you actually wanted. With
got the right count and the corrected characters.
With GCOS line editing is done in a front end processor, only the edited
line is transmitted to the mainframe AFTER carriage return is hit.

I actually remember this. I started using UNIX in July 1975.

# erased the last character typed. @ -erased the whole line typed in so
far.

You could change these if you wished, and usually we did.

[Dennis Boone]

Post by Alan Bowler
Since most of the timeshared terminals at the time were hardcopy,
backspace did not make sense since that would leave an unreadable
smudge if you backspaced and overtyped with the characters you actually
and see if you got the right count and the corrected characters.

Various systems, including SCOPE/HUSTLER and some of the DEC ones, would
not just echo backspaces to printing terminals, but would instead echo
e.g. a backslash, then the characters you were removing from the input,
and when you started typing again, would print e.g. a slash, and then
echo normally.

LOIGN\NGI/GIN

For VMS, I believe this was done in the terminal driver. For HUSTLER,
it would have been done by one or another of the front ends.

De

[Lawrence D'Oliveiro]

Post by Dennis Boone
Various systems, including SCOPE/HUSTLER and some of the DEC ones, would
not just echo backspaces to printing terminals, but would instead echo
e.g. a backslash, then the characters you were removing from the input,
and when you started typing again, would print e.g. a slash, and then
echo normally.
LOIGN\NGI/GIN
For VMS, I believe this was done in the terminal driver. For HUSTLER,
it would have been done by one or another of the front ends.

Yup, for VMS I think this was controlled by SET TERMINAL/SCOPE vs SET
TERMINAL/NOSCOPE.

[Lawrence D'Oliveiro]

As usual, Wikipedia has more than you might ever want to know about
control characters
<https://en.wikipedia.org/wiki/C0_and_C1_control_codes>.

Looking at that lot, it’s hard to see one that could reasonably be
interpreted as “interrupt”. CTRL/C aka “ETX” (“End Of Text”) does seem
like an odd choice; I wonder who it was who decided on that? Some
early DEC engineer, perhaps?

Some systems did use ESC as the interrupt key; but of course that
clashed with its use as a prefix for ANSI escape sequences.

CTRL/D aka “EOT” (“End Of Transmission”) does make some sense as the
EOF indicator; better perhaps than CTRL/Z aka “SUB” (“Substitute”).
Or what about “FS”, the “File Separator”?

And look at that whole block of C1 controls: they were only defined
because it was not considered safe, when extending ASCII to 8 bits, to
put printing characters in these positions. So they might as well
stick some more control characters here. Note the interesting
convention that ESC followed by «char» shall be considered equivalent
to CTRL-«char» with the high bit set.