7

Most of the ASCII character codes make sense in the context of data transmission, e.g. ␄, ␗, ␖ (end of transmission, end of transmission block, synchronisation). However, there are also codes such as ␜, ␝, ␞, ␟, ␙ (file separator, group separator, record separator, unit separator, end of medium) which make less sense in the context of data transmission and more in the context of low-level file management on tape or disk.

As pointed out by Maury Markowitz, the character codes do make sense in the contexts of storing read cards from a card reader, to separate the data from cards. Was this taken to its logical extreme?

Was ASCII used as the basis of any file systems / encapsulation formats? If so, which?

Improve this question
8
  • 1
    The separator control codes just act at a conceptual level above the transmission control codes you mentioned. When transmitting a series of files or records you might separate them with file or record separator control codes respectively. There's really nothing to base a file system on. I don't know if any of the ASCII control codes you mentioned ever got much usage. (Although EOT is used for the default end-of-file character on Unix terminals.)
    – user722
    Commented Jul 19, 2017 at 19:59
  • 4
    0x1a, SUB, is a de facto part of the filing system in CP/M as files must all be a multiple of 128 bytes, so an inline SUB (Ctrl-Z) is usually used to indicate a file that ends anywhere within its final 128 bytes.
    – Tommy
    Commented Jul 19, 2017 at 20:30
  • 2
    The ASCII separators are the conceptual equivalent of what batch systems like IBM's JCL did with punchcards: You had one big stack of cards, which contained several input files, and each file could have a number of records. That has nothing to do with file systems. Also see e.g. here.
    – dirkt
    Commented Jul 19, 2017 at 21:43
  • 2
    And DOS inherited some of that Ctrl-Z behavior from CP/M. Early/ported apps often ignored anything past a Ctrl-Z in a text file. And a Ctrl-Z on the command line (synonym key: F6) signals the end of input from the console when it is being redirected (to a pipe or file). That's still true today in Windows.
    – Euro Micelli
    Commented Jul 20, 2017 at 4:20
  • 1
    A better formulated question might be whether any file format (rather than a file system) used those characters. For example, a US as a column separator (instead of tab) and a RS as a row separator (instead of a CR and/or LF). I've never seen it, but I've often wandered.
    – Euro Micelli
    Commented Jul 20, 2017 at 4:29

2 Answers 2

Reset to default
7

The codes in question were normally used to simulate special interrupts and/or control cards. The idea is that you could take a stack of 80-column punch cards (for instance) and translate them as a series of 80-column lines in a single ASCII file. To indicate a separator card, you'd put in a RS.

Improve this answer
3
  • 1
    ASCII was used to exchange news-wire stories before it was used with "computers" as such. If an ASR-33 teletype receives a control-Q, it will start sending data from its tape reader to the remote end; when it receives a control-S, it will stop. If it receives control-R, it will advance the tape as it punches data received from the remote end; control-T would stop the tape advance (interestingly, the punch itself will still operate, but it will simply punch the same holes over and over again). I suspect other characters were probably used to operate more complex routing equipment.
    – supercat
    Commented Jul 21, 2017 at 19:13
  • 1
    Open up a terminal on a modern Mac or many Linux variants, start something that produces a lot of output, and type ctrl-S. Though unlike on traditional systems, any key will get it unstuck, you don't have to explicitly use ctrl-Q.
    – Chris Stratton
    Commented Jul 22, 2017 at 13:05
  • @ChrisStratton That's a terminal-specific thing. For example, KDE's Konsole and terminals based on its KPart like Yakuake will display a banner saying "Output has been suspended by pressing Ctrl+S. Press Ctrl+Q to resume." instead of making any key into resume. I forget what I did, but I set up a hack years ago at the kernel's terminal layer that made a typed Ctrl+S into a no-op on any terminal, even as my Konsole-based ones claim output was suspended... but that's not "anything resumes".
    – ssokolow
    Commented Feb 14, 2022 at 22:46
2

Data transmission and text file handling are not truly separate aspects in many operating systems. This is very evident in DOS and unix systems, where special files that map to character communications channels exist, and where redirection means that programs can be made to accept either a text file, or terminal input (which traditionally was from a serial line, and is often mapped to device files that behave not entirely unlike one); also, a common way to print from programs that generated plain text, to printers that accept plain text, is to redirect the output to a parallel or serial device file that happens to have a printer connected to the corresponding port.

While the specific control characters mentioned in the question rarely are relevant to printers, they are relevant to both actual serial and emulated terminals - many linux terminal emulators will react to flow control characters etc, often to the confusion of users, eg when CTRL+S/CTRL+Q are accidentally entered (the former will give the appearance of a hung terminal)....

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .