4 ms·

The ASCII table is defective; it is missing a dedicated code for newline. CR and LF aren't dedicated, and have precise cursor movement meanings, rather than be

by snvzz 2y ago

The ASCII table is defective; it is missing a dedicated code for newline. CR and LF aren't dedicated, and have precise cursor movement meanings, rather than being a logical line ender. There was a proposal in the 80s to reassigning the -otherwise useless- VT (vertical tab) character for the purpose. Unfortunately unfruitful.

bregma 2y ago
A separate control character was not needed to indicate where your Hollerith string ended: it ended at the end of the Hollerith string. If you wanted to render a Hollerith string onto print media, you'd often want to feed the line and then return the carriage before printing the next Hollerith string. Of course, that wasn't strictly necessary if you were using a line printer, which would just print the line and advance. The filesystems I used had 5 kinds of file: random-access, sequential, ISAM, Fortran-carriage-control and carriage-return-carriage-control. The only people who used the latter were the eggheads that used that new-fangled C programming language brought over from Bell Lab's experimental Unix system. You're probably just looking for the record separator (036). If you are storing multiple text records and a block of memory, that would be the ideal ASCII code to separate them.
- snvzz 2y ago
  >You're probably just looking for the record separator (036). Certainly not for records that are made of multiple lines.
Gormo 2y ago
> Unfortunately unfruitful. Fortunately unfruitful, since if it had gained adoption, there'd be a mix of three different line endings (and combinations thereof) in widespread use, instead of two.
- snvzz 2y ago
  >widespread use We are talking about the early 80s at worst. It would have consolidated by now.
  - Gormo 2y ago
    I'm not sure I'm following. We have had multiple line endings (based on combinations of two particular characters) in common use, without consolidating to a common standard, for decades -- why would introducing a third character have made that more likely?
    - snvzz 2y ago
      Because the reason consolidation has not happened is simple: There's no right answer, as there's no code explicitly defined by ASCII for ending a line. A major oversight. If a code had been timely assigned, we'd have the correct way (predominant), and the legacy ways (mostly gone by now).
- snvzz 2y ago
  >there'd be a mix of three We already got four. \n, \r, \n\r and \r\n.

by snvzz 2y ago

bregma 2y ago

A separate control character was not needed to indicate where your Hollerith string ended: it ended at the end of the Hollerith string. If you wanted to render a Hollerith string onto print media, you'd often want to feed the line and then return the carriage before printing the next Hollerith string. Of course, that wasn't strictly necessary if you were using a line printer, which would just print the line and advance. The filesystems I used had 5 kinds of file: random-access, sequential, ISAM, Fortran-carriage-control and carriage-return-carriage-control. The only people who used the latter were the eggheads that used that new-fangled C programming language brought over from Bell Lab's experimental Unix system. You're probably just looking for the record separator (036). If you are storing multiple text records and a block of memory, that would be the ideal ASCII code to separate them.

snvzz 2y ago
>You're probably just looking for the record separator (036). Certainly not for records that are made of multiple lines.

Gormo 2y ago

> Unfortunately unfruitful. Fortunately unfruitful, since if it had gained adoption, there'd be a mix of three different line endings (and combinations thereof) in widespread use, instead of two.

snvzz 2y ago
>widespread use We are talking about the early 80s at worst. It would have consolidated by now.
- Gormo 2y ago
  I'm not sure I'm following. We have had multiple line endings (based on combinations of two particular characters) in common use, without consolidating to a common standard, for decades -- why would introducing a third character have made that more likely?
  - snvzz 2y ago
    Because the reason consolidation has not happened is simple: There's no right answer, as there's no code explicitly defined by ASCII for ending a line. A major oversight. If a code had been timely assigned, we'd have the correct way (predominant), and the legacy ways (mostly gone by now).
snvzz 2y ago
>there'd be a mix of three We already got four. \n, \r, \n\r and \r\n.