Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #210897 > unrolled thread
| Started by | Gareth Evans <headstone255@yahoo.com> |
|---|---|
| First post | 2020-04-12 11:59 +0100 |
| Last post | 2020-08-22 18:55 -0700 |
| Articles | 20 on this page of 169 — 32 participants |
Back to article view | Back to alt.folklore.computers
CR or LF? Gareth Evans <headstone255@yahoo.com> - 2020-04-12 11:59 +0100
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-04-12 20:35 +0000
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-04-12 16:52 -0400
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-04-13 22:16 +0000
Re: CR or LF? Gareth Evans <headstone255@yahoo.com> - 2020-04-12 22:48 +0100
Re: CR or LF? Mike Spencer <mds@bogus.nodomain.nowhere> - 2020-04-12 19:44 -0300
Re: CR or LF? Douglas Miller <durgadas311@gmail.com> - 2020-04-12 16:38 -0700
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-04-13 19:03 +0000
Re: CR or LF? Douglas Miller <durgadas311@gmail.com> - 2020-04-13 14:12 -0700
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-04-13 22:30 +0000
Re: CR or LF? Douglas Miller <durgadas311@gmail.com> - 2020-04-13 16:00 -0700
Re: CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-04-13 21:22 +0000
Re: CR or LF? Thomas Koenig <tkoenig@netcologne.de> - 2020-04-14 09:40 +0000
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-04-13 17:56 -0700
Re: CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-04-13 03:32 +0000
Re: CR or LF? "Carlos E.R." <robin_listas@es.invalid> - 2020-04-14 05:26 +0200
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-04-12 22:11 -0700
Re: CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-04-13 17:15 +0000
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-04-13 16:40 -0700
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-04-13 17:29 -0700
Re: CR or LF? Douglas Miller <durgadas311@gmail.com> - 2020-04-13 18:18 -0700
Re: CR or LF? Niklas Karlsson <anksil@yahoo.se> - 2020-04-16 13:40 +0000
Re: CR or LF? maus <maus@dmaus.org> - 2020-04-17 11:00 +0000
Re: CR or LF? Niklas Karlsson <anksil@yahoo.se> - 2020-04-18 09:56 +0000
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-04-13 21:37 -0400
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-04-14 14:51 -0700
Re: CR or LF? Bob Eager <news0073@eager.cx> - 2020-04-14 07:45 +0000
Re: CR or LF? Gareth Evans <headstone255@yahoo.com> - 2020-04-14 11:38 +0100
Re: CR or LF? "Carlos E.R." <robin_listas@es.invalid> - 2020-04-14 15:28 +0200
Re: CR or LF? nobody@example.org (Scott) - 2020-04-14 15:27 +0000
Re: CR or LF? Gareth Evans <headstone255@yahoo.com> - 2020-04-14 17:37 +0100
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-04-14 15:00 -0700
Re: CR or LF? fred_weigel@hotmail.com - 2020-05-22 17:09 -0700
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-23 03:37 -0700
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-23 08:36 -0400
Re: CR or LF? robin.vowels@gmail.com - 2020-05-23 05:38 -0700
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-05-23 08:58 -0400
Re: base64, not really CR or LF? John Levine <johnl@taugh.com> - 2020-05-23 18:42 +0000
Re: CR or LF? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-05-23 19:28 +0000
Re: CR or LF? Bob Eager <news0073@eager.cx> - 2020-05-23 20:27 +0000
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-05-23 14:30 -0700
Re: CR or LF? "Kerr-Mudd,John" <notsaying@invalid.org> - 2020-05-24 10:21 +0000
Re: CR or LF? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-05-24 06:06 +0000
Re: CR or LF? Bob Eager <news0073@eager.cx> - 2020-05-24 10:45 +0000
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-24 07:03 -0700
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-24 10:43 -0400
Re: CR or LF? Jan van den Broek <fortytwo@xs4all.nl> - 2020-06-05 22:22 +0100
Re: CR or LF? Mike Spencer <mds@bogus.nodomain.nowhere> - 2020-04-14 17:49 -0300
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-04-14 06:29 -0700
Re: CR or LF? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-04-18 08:42 +0100
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-04-18 11:33 -0700
Re: CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-04-18 19:11 +0000
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-04-18 18:32 -0400
Re: CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-04-19 01:55 +0000
Re: CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-04-18 20:03 +0000
Re: CR or LF? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-04-18 22:44 +0100
Re: CR or LF? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-19 08:46 +0000
Re: CR or LF? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-04-19 10:58 +0100
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-04-18 22:22 +0000
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-04-18 18:55 -0400
re: CRLF Peter Flass <peter_flass@yahoo.com> - 2020-04-18 18:03 -0700
Re: CR or LF? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-19 08:55 +0000
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-04-19 08:16 -0400
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-04-19 09:19 -0400
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-04-19 10:24 -0400
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-04-19 10:47 -0700
Re: CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-04-20 16:02 +0000
Re: CR or LF? Jan van den Broek <fortytwo@xs4all.nl> - 2020-05-05 16:32 +0100
Re: CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-04-19 14:54 +0000
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-04-19 12:19 -0400
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-04-19 10:47 -0700
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-04-19 09:26 -0700
Re: CR or LF? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2020-04-20 17:40 +0800
Re: CR or LF? Fred Smith <fred@thejanitor.corp> - 2020-04-20 23:05 +0000
Re: CR or LF? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-21 06:07 +0000
Re: CR or LF? Rich Alderson <news@alderson.users.panix.com> - 2020-04-22 15:08 -0400
Re: CR or LF? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-22 20:22 +0000
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-04-22 19:40 -0400
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-04-22 23:23 -0700
Re: CR or LF? robin.vowels@gmail.com - 2020-04-23 03:01 -0700
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-04-19 10:47 -0700
Re: CR or LF? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-04-13 19:54 +0100
Re: CR or LF? hancock4@bbs.cpcn.com - 2020-08-22 11:18 -0700
Re: CR or LF? "Carlos E.R." <robin_listas@es.invalid> - 2020-04-14 05:24 +0200
Re: CR or LF? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-04-18 08:44 +0100
Re: CR or LF? "Carlos E.R." <robin_listas@es.invalid> - 2020-04-18 12:08 +0200
Re: CR or LF? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-04-18 12:02 +0100
Re: CR or LF? "Carlos E.R." <robin_listas@es.invalid> - 2020-04-18 21:50 +0200
Re: CR or LF? usenet@only.tnx (Questor) - 2020-04-18 03:40 +0000
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-23 03:40 -0700
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-23 08:38 -0400
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-23 08:02 -0700
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-23 11:07 -0400
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-23 11:27 -0700
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-05-23 12:27 -0700
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-23 18:21 -0400
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-05-23 20:10 +0000
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-24 08:32 -0700
Re: CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-05-24 16:25 +0000
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-05-24 18:29 +0000
Re: CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-05-25 02:00 +0000
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-05-25 16:28 +0000
Re: CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-05-26 14:06 +0000
Re: CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-05-26 15:14 +0000
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-05-25 10:55 -0700
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-05-25 15:04 -0400
Re: CR or LF? robin.vowels@gmail.com - 2020-05-24 21:32 -0700
Re: CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-05-25 15:44 +0000
Re: mainframe I/O, was CR or LF? John Levine <johnl@taugh.com> - 2020-05-25 16:32 +0000
Re: mainframe I/O, was CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-05-26 00:39 +0000
Re: mainframe I/O, was CR or LF? antispam@math.uni.wroc.pl - 2020-05-31 00:21 +0000
Re: mainframe I/O, was CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-30 21:59 -0400
Re: mainframe I/O, was CR or LF? David Wade <g4ugm@dave.invalid> - 2020-05-31 09:30 +0100
Re: mainframe I/O, was CR or LF? antispam@math.uni.wroc.pl - 2020-05-31 15:48 +0000
Re: mainframe I/O, was CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-05-31 13:49 -0700
Re: mainframe I/O, was CR or LF? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2020-06-01 16:28 +0000
Re: mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-01 18:48 +0000
Re: mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-01 16:27 +0000
Re: mainframe I/O, was CR or LF? usenet@only.tnx (Questor) - 2020-06-02 19:12 +0000
Re: mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-02 20:28 +0000
Re: mainframe I/O, was CR or LF? David Wade <g4ugm@dave.invalid> - 2020-06-03 09:13 +0100
Re: mainframe I/O, was CR or LF? Fred Smith <fred@thejanitor.corp> - 2020-06-03 08:33 +0000
Re: mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-03 16:20 +0000
Re: mainframe I/O, was CR or LF? usenet@only.tnx (Questor) - 2020-06-03 18:25 +0000
Re: mainframe I/O, was CR or LF? Rich Alderson <news@alderson.users.panix.com> - 2020-06-03 17:20 -0400
Re: mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-04 15:20 +0000
Re: mainframe I/O, was CR or LF? John Levine <johnl@taugh.com> - 2020-06-04 19:51 +0000
Re: mainframe I/O, was CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-06-04 16:26 -0700
Re: mainframe I/O, was CR or LF? usenet@only.tnx (Questor) - 2020-06-05 18:46 +0000
Re: mainframe I/O, was CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-06-05 12:26 -0700
Re: mainframe I/O, was CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-06-05 13:28 -0700
Re: mainframe I/O, was CR or LF? David Lesher <wb8foz@panix.com> - 2020-06-08 01:03 +0000
Re: PDP-11s, was mainframe I/O, was CR or LF? John Levine <johnl@taugh.com> - 2020-06-06 00:08 +0000
Re: mainframe I/O, was CR or LF? usenet@only.tnx (Questor) - 2020-06-04 17:41 +0000
Re: mainframe I/O, was CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-06-04 16:26 -0700
Re: mainframe I/O, was CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-06-04 17:04 -0700
Re: mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-04 15:18 +0000
Re: memory sizes, mainframe I/O, was CR or LF? John Levine <johnl@taugh.com> - 2020-06-04 20:53 +0000
Re: memory sizes, mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-04 22:22 +0000
Re: memory sizes, mainframe I/O, was CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-06-04 19:27 -0400
Re: memory sizes, mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-05 16:10 +0000
Re: memory sizes, mainframe I/O, was CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-06-05 10:03 -0700
Re: memory sizes, mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-05 20:29 +0000
Re: memory sizes, mainframe I/O, was CR or LF? usenet@only.tnx (Questor) - 2020-06-05 18:47 +0000
Re: mainframe I/O, was CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-06-04 16:26 -0700
Re: mainframe I/O, was CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-06-01 16:32 +0000
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-05-25 10:55 -0700
Re: CR or LF? Anne & Lynn Wheeler <lynn@garlic.com> - 2020-05-25 15:04 -1000
Re: CR or LF? Peter Flass <peter_flass@yahoo.com> - 2020-05-26 12:56 -0700
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-26 14:15 -0700
Re: CR or LF? robin.vowels@gmail.com - 2020-05-25 21:41 -0700
Re: CR or LF? Thomas Koenig <tkoenig@netcologne.de> - 2020-05-28 11:50 +0000
Re: CR or LF? Bob Eager <news0073@eager.cx> - 2020-05-28 11:56 +0000
Re: CR or LF? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-05-30 14:49 +0000
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-05-30 17:39 +0000
Re: CR or LF? scott@slp53.sl.home (Scott Lurndal) - 2020-05-30 19:07 +0000
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-05-30 19:32 +0000
Re: CR or LF? Quadibloc <jsavard@ecn.ab.ca> - 2020-05-30 13:10 -0700
Re: CR or LF? John Levine <johnl@taugh.com> - 2020-05-30 20:43 +0000
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-05-30 15:50 -0400
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-30 16:30 -0400
Re: CR or LF? Dan Espen <dan1espen@gmail.com> - 2020-05-30 19:42 -0400
Re: CR or LF? J. Clarke <jclarke.873638@gmail.com> - 2020-05-30 22:17 -0400
Re: CR or LF? Ahem A Rivet's Shot <steveo@eircom.net> - 2020-05-31 09:45 +0100
Re: CR or LF? usenet@only.tnx (Questor) - 2020-05-25 18:37 +0000
Re: CR or LF? Bob Eager <news0073@eager.cx> - 2020-05-25 19:52 +0000
Re: CR or LF? usenet@only.tnx (Questor) - 2020-05-25 07:37 +0000
Re: CR or LF? hancock4@bbs.cpcn.com - 2020-08-22 11:15 -0700
Re: CR or LF? Robin Vowels <robin.vowels@gmail.com> - 2020-08-22 18:55 -0700
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Douglas Miller <durgadas311@gmail.com> |
|---|---|
| Date | 2020-04-13 18:18 -0700 |
| Message-ID | <1e8c361b-fb4e-4782-95c0-60d25a8b2783@googlegroups.com> |
| In reply to | #210945 |
On Monday, April 13, 2020 at 7:29:55 PM UTC-5, Peter Flass wrote: >... > > Besides, thinking about this, what’s the distinction between a two-byte > count field and a two-byte (CRLF) delimiter? > > -- > Pete Think about how all this evolved. The first ASCII "text files" were probably punched paper tape generated on teletypes and transmitted to a remote (where possibly a copy of the paper tape "file" was made). These text files needed to be raw images of the codes necessary to print the document. On computers, it was much simpler to be able to directly output a file to a peripheral without having to do any (or much) processing on it. For example, "PIP LST:=FOOBAR.PRN". Certainly, an application is free to invent their own format for storing things in files, but for universal interchange there has to be a standard. Slight platform variations (CR, LF, CR+LF) aside.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Karlsson <anksil@yahoo.se> |
|---|---|
| Date | 2020-04-16 13:40 +0000 |
| Message-ID | <hfr5idFrqbkU1@mid.individual.net> |
| In reply to | #210948 |
On 2020-04-14, Douglas Miller <durgadas311@gmail.com> wrote: > On Monday, April 13, 2020 at 7:29:55 PM UTC-5, Peter Flass wrote: >>... >> >> Besides, thinking about this, what’s the distinction between a two-byte >> count field and a two-byte (CRLF) delimiter? > > Think about how all this evolved. The first ASCII "text files" were probably punched paper tape generated on teletypes and transmitted to a remote (where possibly a copy of the paper tape "file" was made). These text files needed to be raw images of the codes necessary to print the document. On computers, it was much simpler to be able to directly output a file to a peripheral without having to do any (or much) processing on it. For example, "PIP LST:=FOOBAR.PRN". Certainly, an application is free to invent their own format for storing things in files, but for universal interchange there has to be a standard. Slight platform variations (CR, LF, CR+LF) aside. Ironic that the main text of your posting is all one long line, no breaks. Niklas -- "And the attacks have been totally random, so that rules out border skirmishes or political disagreements. there's no one obvious to blame." "Which means they'll blame each other, randomly." -- Sheridan and Delenn in Babylon 5:"In the Kingdom of the Blind"
[toc] | [prev] | [next] | [standalone]
| From | maus <maus@dmaus.org> |
|---|---|
| Date | 2020-04-17 11:00 +0000 |
| Message-ID | <slrnr9j32e.3g1.maus@dmaus.org> |
| In reply to | #210994 |
On 2020-04-16, Niklas Karlsson <anksil@yahoo.se> wrote: > On 2020-04-14, Douglas Miller <durgadas311@gmail.com> wrote: >> On Monday, April 13, 2020 at 7:29:55 PM UTC-5, Peter Flass wrote: >>>... >>> >>> Besides, thinking about this, what’s the distinction between a two-byte >>> count field and a two-byte (CRLF) delimiter? >> >> Think about how all this evolved. The first ASCII "text files" were probably punched paper tape generated on teletypes and transmitted to a remote (where possibly a copy of the paper tape "file" was made). These text files needed to be raw images of the codes necessary to print the document. On computers, it was much simpler to be able to directly output a file to a peripheral without having to do any (or much) processing on it. For example, "PIP LST:=FOOBAR.PRN". Certainly, an application is free to invent their own format for storing things in files, but for universal interchange there has to be a standard. Slight platform variations (CR, LF, CR+LF) aside. > > Ironic that the main text of your posting is all one long line, no > breaks. > > Niklas comes from groups.google.com Irritating. -- greymaus
[toc] | [prev] | [next] | [standalone]
| From | Niklas Karlsson <anksil@yahoo.se> |
|---|---|
| Date | 2020-04-18 09:56 +0000 |
| Message-ID | <hg0176FsqfpU1@mid.individual.net> |
| In reply to | #211004 |
On 2020-04-17, maus <maus@dmaus.org> wrote:
> On 2020-04-16, Niklas Karlsson <anksil@yahoo.se> wrote:
>>
>> Ironic that the main text of your posting is all one long line, no
>> breaks.
>
> comes from groups.google.com Irritating.
I see. If I were to post through there, I'd probably type up my post in
a text editor that wrapped at 72-80 cols or so and then paste it into
google.
Niklas
--
I always buy white autos only. That way, the cops call in a speeding
red car once I've gone by, but the ones at the roadblocks see a blue
one coming their way.
-- J.D. Baldwin
[toc] | [prev] | [next] | [standalone]
| From | J. Clarke <jclarke.873638@gmail.com> |
|---|---|
| Date | 2020-04-13 21:37 -0400 |
| Message-ID | <vr4a9fd2eaq9m4g33a4s169uftrm4h8iu4@4ax.com> |
| In reply to | #210945 |
On Mon, 13 Apr 2020 17:29:53 -0700, Peter Flass <peter_flass@yahoo.com> wrote: >Peter Flass <peter_flass@yahoo.com> wrote: >> Quadibloc <jsavard@ecn.ab.ca> wrote: >>> On Sunday, April 12, 2020 at 5:00:17 AM UTC-6, Gareth Evans wrote: >>> >>>> But, if device behaviours are to be encoded in >>>> printable text, surely the end-of-line marker >>>> should not be LF, but CR, to reflect, for >>>> example, the behaviour of typewriters? >>> >>> It is certainly true that, on the System/360 time-sharing system that I used >>> first, on ASCII terminals, one pressed the carriage return key, and not the line >>> feed key, to end a line, because it was certain to be present, and when both >>> were present, it was usually larger or more conveniently placed. >>> >>> And the Macintosh, at least originally, used CR rather than LF to separate lines >>> in its text files. MS-DOS used <CR><LF>. So I do find CR to be a bit more >>> natural than LF. >>> >>> However, in my opinion, using _any_ character to delimit lines of text in a text >>> file is a bad idea. Instead of a text file being a bunch of C strings (which, of >>> course, are ended by NUL) it should be a bunch of Pascal strings (n, followd by >>> n characters). >>> >>> Two benefits. >>> >>> Better protection against buffer overflows. >>> >>> No strange problems when one creates a file where binary data and text are >>> mixed, since now all 256 bytes are legal, no value means "end of record". >>> >>> John Savard >>> >> >> I agree. Using a character as a delimiter causes all kinds of problems. >> > >Besides, thinking about this, what’s the distinction between a two-byte >count field and a two-byte (CRLF) delimiter? The difference is that a one-bit error in a CRLF means that you have an extra long line with a garbage character in the middle A one-bit error in a count field means that the counts for the entire rest of the message are garbled and you don't know where the end of it is.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2020-04-14 14:51 -0700 |
| Message-ID | <2213ef6d-06fc-4052-aa28-8a43126296a2@googlegroups.com> |
| In reply to | #210950 |
On Monday, April 13, 2020 at 7:38:00 PM UTC-6, J. Clarke wrote: > The difference is that a one-bit error in a CRLF means that you have > an extra long line with a garbage character in the middle A one-bit > error in a count field means that the counts for the entire rest of > the message are garbled and you don't know where the end of it is. I definitely agree that no one should try to invent a TTY terminal that uses count fields instead of CR and LF characters for use in RTTY. On computer disk files, however, every disk block has a CRC field, and so if there's an error, you won't be able to see the data that is in error anyways. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <news0073@eager.cx> |
|---|---|
| Date | 2020-04-14 07:45 +0000 |
| Message-ID | <hfl816FqsqmU2@mid.individual.net> |
| In reply to | #210945 |
On Mon, 13 Apr 2020 17:29:53 -0700, Peter Flass wrote: > Peter Flass <peter_flass@yahoo.com> wrote: >> Quadibloc <jsavard@ecn.ab.ca> wrote: >>> On Sunday, April 12, 2020 at 5:00:17 AM UTC-6, Gareth Evans wrote: >>> >>>> But, if device behaviours are to be encoded in printable text, surely >>>> the end-of-line marker should not be LF, but CR, to reflect, for >>>> example, the behaviour of typewriters? >>> >>> It is certainly true that, on the System/360 time-sharing system that >>> I used first, on ASCII terminals, one pressed the carriage return key, >>> and not the line feed key, to end a line, because it was certain to be >>> present, and when both were present, it was usually larger or more >>> conveniently placed. >>> >>> And the Macintosh, at least originally, used CR rather than LF to >>> separate lines in its text files. MS-DOS used <CR><LF>. So I do find >>> CR to be a bit more natural than LF. >>> >>> However, in my opinion, using _any_ character to delimit lines of text >>> in a text file is a bad idea. Instead of a text file being a bunch of >>> C strings (which, of course, are ended by NUL) it should be a bunch of >>> Pascal strings (n, followd by n characters). >>> >>> Two benefits. >>> >>> Better protection against buffer overflows. >>> >>> No strange problems when one creates a file where binary data and text >>> are mixed, since now all 256 bytes are legal, no value means "end of >>> record". >>> >>> John Savard >>> >>> >> I agree. Using a character as a delimiter causes all kinds of problems. >> >> > Besides, thinking about this, what’s the distinction between a two-byte > count field and a two-byte (CRLF) delimiter? The latter can handle a line of any length. -- Using UNIX since v6 (1975)... Use the BIG mirror service in the UK: http://www.mirrorservice.org
[toc] | [prev] | [next] | [standalone]
| From | Gareth Evans <headstone255@yahoo.com> |
|---|---|
| Date | 2020-04-14 11:38 +0100 |
| Message-ID | <r743re$r8$1@dont-email.me> |
| In reply to | #210953 |
On 14/04/2020 08:45, Bob Eager wrote: > On Mon, 13 Apr 2020 17:29:53 -0700, Peter Flass wrote: > >> Besides, thinking about this, what’s the distinction between a two-byte >> count field and a two-byte (CRLF) delimiter? > > The latter can handle a line of any length. I have yet to encounter a line of any length that exceeds 65,535 characters! :-)
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2020-04-14 15:28 +0200 |
| Message-ID | <odqgmg-22l.ln1@Telcontar.valinor> |
| In reply to | #210956 |
On 14/04/2020 12.38, Gareth Evans wrote: > On 14/04/2020 08:45, Bob Eager wrote: >> On Mon, 13 Apr 2020 17:29:53 -0700, Peter Flass wrote: >> >>> Besides, thinking about this, what’s the distinction between a two-byte >>> count field and a two-byte (CRLF) delimiter? >> >> The latter can handle a line of any length. > > > I have yet to encounter a line of any length that exceeds > 65,535 characters! :-) I have seen them. Rare, but I have seen them. :-) -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | nobody@example.org (Scott) |
|---|---|
| Date | 2020-04-14 15:27 +0000 |
| Message-ID | <5e95d4f8.126415172@core> |
| In reply to | #210956 |
On Tue, 14 Apr 2020 11:38:24 +0100, Gareth Evans <headstone255@yahoo.com> wrote: >On 14/04/2020 08:45, Bob Eager wrote: >> On Mon, 13 Apr 2020 17:29:53 -0700, Peter Flass wrote: >> >>> Besides, thinking about this, what’s the distinction between a two-byte >>> count field and a two-byte (CRLF) delimiter? >> >> The latter can handle a line of any length. > > >I have yet to encounter a line of any length that exceeds >65,535 characters! :-) Physically, no, of course. On disk? Yes. It wasn't that long ago that I laid out the basic structure of an image processing suite. I decided that the value of a few bytes of memory exceeded the value of handling images larger than 64k pixels square. Ridiculous. I could not foresee any such thing ever being useful. Fast forward a few decades and, well...that was dumb, wasn't it?
[toc] | [prev] | [next] | [standalone]
| From | Gareth Evans <headstone255@yahoo.com> |
|---|---|
| Date | 2020-04-14 17:37 +0100 |
| Message-ID | <r74osf$mmv$1@dont-email.me> |
| In reply to | #210963 |
On 14/04/2020 16:27, Scott wrote: > On Tue, 14 Apr 2020 11:38:24 +0100, Gareth Evans > <headstone255@yahoo.com> wrote: > >> On 14/04/2020 08:45, Bob Eager wrote: >>> On Mon, 13 Apr 2020 17:29:53 -0700, Peter Flass wrote: >>> >>>> Besides, thinking about this, what’s the distinction between a two-byte >>>> count field and a two-byte (CRLF) delimiter? >>> >>> The latter can handle a line of any length. >> >> >> I have yet to encounter a line of any length that exceeds >> 65,535 characters! :-) > > Physically, no, of course. On disk? Yes. > > It wasn't that long ago that I laid out the basic structure of an > image processing suite. I decided that the value of a few bytes of > memory exceeded the value of handling images larger than 64k pixels > square. Ridiculous. I could not foresee any such thing ever being > useful. Fast forward a few decades and, well...that was dumb, wasn't > it? > images are not ASCII text with end of line markers.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2020-04-14 15:00 -0700 |
| Message-ID | <39525ef8-01aa-49bd-8010-4923265f8729@googlegroups.com> |
| In reply to | #210964 |
On Tuesday, April 14, 2020 at 10:37:41 AM UTC-6, Gareth Evans wrote: > images are not ASCII text with end of line markers. Indeed. So, on MTS, an operating system where text files either were ISAM files where each line was from 0 to 255 characters, or sequential files where each line was from 0 to 32,767 characters (they didn't bother with unsigned)... if a file was going to contain a binary blob of data, in order to fit, it was turned into a file where every record was the same length, perhaps 80, 128, or 64 characters. This would be different from what we're used to in Windows or Unix. Of course, if MTS can mark a file as LINE or SEQ, then an operating system were *text* files are usually of either the LINE or SEQ types could also support _other_ file types. So you could have PTAP files that delimit records with CR, for example, and DIRECT files which reserve a chunk of disk space so that any byte can be directly accessed by position, and return as many bytes as are requested. (If one calls the "return a record" routine, these could also use the CR as a record delimiter.) So while the _default_ text file type would be different from what is used now, the file type seen on today's computers would still be available (which is DIRECT with a character delimiter; PTAP is a sequential type for which seek to character N would be impractical, and that typically hasn't been found to be needed on today's microcomputer systems). John Savard
[toc] | [prev] | [next] | [standalone]
| From | fred_weigel@hotmail.com |
|---|---|
| Date | 2020-05-22 17:09 -0700 |
| Message-ID | <e20fe653-a4ae-403f-8c1d-2cffb4afffa0@googlegroups.com> |
| In reply to | #210964 |
On Tuesday, April 14, 2020 at 12:37:41 PM UTC-4, Gareth Evans wrote: > On 14/04/2020 16:27, Scott wrote: > > On Tue, 14 Apr 2020 11:38:24 +0100, Gareth Evans > > <headstone255@yahoo.com> wrote: > > > >> On 14/04/2020 08:45, Bob Eager wrote: > >>> On Mon, 13 Apr 2020 17:29:53 -0700, Peter Flass wrote: > >>> > >>>> Besides, thinking about this, what’s the distinction between a two-byte > >>>> count field and a two-byte (CRLF) delimiter? > >>> > >>> The latter can handle a line of any length. > >> > >> > >> I have yet to encounter a line of any length that exceeds > >> 65,535 characters! :-) > > > > Physically, no, of course. On disk? Yes. > > > > It wasn't that long ago that I laid out the basic structure of an > > image processing suite. I decided that the value of a few bytes of > > memory exceeded the value of handling images larger than 64k pixels > > square. Ridiculous. I could not foresee any such thing ever being > > useful. Fast forward a few decades and, well...that was dumb, wasn't > > it? > > > > images are not ASCII text with end of line markers. Oddly, Gareth, a lot of images are exactly that. When base64 encoded, or otherwise transmitted. Its only when interpreted by a web browser that they become... images. FredW
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2020-05-23 03:37 -0700 |
| Message-ID | <d1dc7041-d9d0-4096-811f-da7879e5763a@googlegroups.com> |
| In reply to | #211549 |
On Friday, May 22, 2020 at 6:09:21 PM UTC-6, fred_...@hotmail.com wrote: > On Tuesday, April 14, 2020 at 12:37:41 PM UTC-4, Gareth Evans wrote: > > images are not ASCII text with end of line markers. > Oddly, Gareth, a lot of images are exactly that. When base64 encoded, > or otherwise transmitted. Its only when interpreted by a web browser > that they become... images. The point is that neither the JPEG nor GIF image formats consist of ASCII text with end of line markers. An image on the hard disk of a computer is what an image is. What transmission formats are used by the HTML and WWW has nothing to do with what images "are". Of course, converting binaries to a format which transmits only 6 bits per character is a huge waste of bandwidth, which shows that there is room for improvement in those protocols. Instead of expanding binaries by over 33%, it should be possible to limit the expansion to less than 2%. John Savard
[toc] | [prev] | [next] | [standalone]
| From | J. Clarke <jclarke.873638@gmail.com> |
|---|---|
| Date | 2020-05-23 08:36 -0400 |
| Message-ID | <026icftks13865oijtvfnf9te40e5qdcef@4ax.com> |
| In reply to | #211553 |
On Sat, 23 May 2020 03:37:47 -0700 (PDT), Quadibloc <jsavard@ecn.ab.ca> wrote: >On Friday, May 22, 2020 at 6:09:21 PM UTC-6, fred_...@hotmail.com wrote: >> On Tuesday, April 14, 2020 at 12:37:41 PM UTC-4, Gareth Evans wrote: > >> > images are not ASCII text with end of line markers. > >> Oddly, Gareth, a lot of images are exactly that. When base64 encoded, >> or otherwise transmitted. Its only when interpreted by a web browser >> that they become... images. > >The point is that neither the JPEG nor GIF image formats consist of ASCII text >with end of line markers. An image on the hard disk of a computer is what an >image is. What transmission formats are used by the HTML and WWW has nothing to >do with what images "are". One could argue that a computer program stored in a ZIP file does not consiste of ASCII text with end of line markers, because in the ZIP file it has been compressed. JPEG and GIF are both compressed formats. >Of course, converting binaries to a format which transmits only 6 bits per >character is a huge waste of bandwidth, which shows that there is room for >improvement in those protocols. Instead of expanding binaries by over 33%, it >should be possible to limit the expansion to less than 2%. > >John Savard
[toc] | [prev] | [next] | [standalone]
| From | robin.vowels@gmail.com |
|---|---|
| Date | 2020-05-23 05:38 -0700 |
| Message-ID | <dcac36f4-abae-4e0c-9794-6deca4108f59@googlegroups.com> |
| In reply to | #211553 |
On Saturday, May 23, 2020 at 8:37:48 PM UTC+10, Quadibloc wrote: > On Friday, May 22, 2020 at 6:09:21 PM UTC-6, f..._...@hotmail.com wrote: > > On Tuesday, April 14, 2020 at 12:37:41 PM UTC-4, Gareth Evans wrote: > > > > images are not ASCII text with end of line markers. > > > Oddly, Gareth, a lot of images are exactly that. When base64 encoded, > > or otherwise transmitted. Its only when interpreted by a web browser > > that they become... images. > > The point is that neither the JPEG nor GIF image nor TIFF nor PCX nor pretty all of the image formats > formats consist of ASCII text > with end of line markers. An image on the hard disk of a computer is what an > image is. What transmission formats are used by the HTML and WWW has nothing to > do with what images "are". > > Of course, converting binaries to a format which transmits only 6 bits per > character is a huge waste of bandwidth, which shows that there is room for > improvement in those protocols. Instead of expanding binaries by over 33%, it > should be possible to limit the expansion to less than 2%. > > John Savard
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <dan1espen@gmail.com> |
|---|---|
| Date | 2020-05-23 08:58 -0400 |
| Message-ID | <rab6lr$2bd$1@dont-email.me> |
| In reply to | #211556 |
robin.vowels@gmail.com writes: > On Saturday, May 23, 2020 at 8:37:48 PM UTC+10, Quadibloc wrote: >> On Friday, May 22, 2020 at 6:09:21 PM UTC-6, f..._...@hotmail.com wrote: >> > On Tuesday, April 14, 2020 at 12:37:41 PM UTC-4, Gareth Evans wrote: >> >> > > images are not ASCII text with end of line markers. >> >> > Oddly, Gareth, a lot of images are exactly that. When base64 encoded, >> > or otherwise transmitted. Its only when interpreted by a web browser >> > that they become... images. >> >> The point is that neither the JPEG nor GIF image > > nor TIFF nor PCX nor pretty all of the image formats 2 notable exceptions, XPM and SVG, both are text. SVG is interesting because it doesn't necessarily contain a bit mapped image, it can contain vectors, shapes, text. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2020-05-23 18:42 +0000 |
| Subject | Re: base64, not really CR or LF? |
| Message-ID | <rabqrc$3076$2@gal.iecc.com> |
| In reply to | #211553 |
In article <d1dc7041-d9d0-4096-811f-da7879e5763a@googlegroups.com>, Quadibloc <jsavard@ecn.ab.ca> wrote: >The point is that neither the JPEG nor GIF image formats consist of ASCII text >with end of line markers. An image on the hard disk of a computer is what an >image is. What transmission formats are used by the HTML and WWW has nothing to >do with what images "are". > >Of course, converting binaries to a format which transmits only 6 bits per >character is a huge waste of bandwidth, which shows that there is room for >improvement in those protocols. Instead of expanding binaries by over 33%, it >should be possible to limit the expansion to less than 2%. There are plenty of ways to send mail attachments without b64 encoding, e.g. BINARYMIME and CHUNKING, but for the most part nobody cares. People who ship around giant files use dropbox and the like. -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-05-23 19:28 +0000 |
| Message-ID | <slrnrciubr.1r7q.grahn+nntp@frailea.sa.invalid> |
| In reply to | #211553 |
On Sat, 2020-05-23, Quadibloc wrote: > On Friday, May 22, 2020 at 6:09:21 PM UTC-6, fred_...@hotmail.com wrote: >> On Tuesday, April 14, 2020 at 12:37:41 PM UTC-4, Gareth Evans wrote: > >> > images are not ASCII text with end of line markers. > >> Oddly, Gareth, a lot of images are exactly that. When base64 encoded, >> or otherwise transmitted. Its only when interpreted by a web browser >> that they become... images. > > The point is that neither the JPEG nor GIF image formats consist of ASCII text > with end of line markers. An image on the hard disk of a computer is what an > image is. What transmission formats are used by the HTML and WWW has nothing to > do with what images "are". > > Of course, converting binaries to a format which transmits only 6 bits per > character is a huge waste of bandwidth, which shows that there is room for > improvement in those protocols. Since the example was web browsers above, the protocol is HTTP, and it doesn't use base64. It's designed so that you can feed the image file as-is over the protocol. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Bob Eager <news0073@eager.cx> |
|---|---|
| Date | 2020-05-23 20:27 +0000 |
| Message-ID | <hitf8mFk890U16@mid.individual.net> |
| In reply to | #211564 |
On Sat, 23 May 2020 19:28:59 +0000, Jorgen Grahn wrote: > On Sat, 2020-05-23, Quadibloc wrote: >> On Friday, May 22, 2020 at 6:09:21 PM UTC-6, fred_...@hotmail.com >> wrote: >>> On Tuesday, April 14, 2020 at 12:37:41 PM UTC-4, Gareth Evans wrote: >> >>> > images are not ASCII text with end of line markers. >> >>> Oddly, Gareth, a lot of images are exactly that. When base64 encoded, >>> or otherwise transmitted. Its only when interpreted by a web browser >>> that they become... images. >> >> The point is that neither the JPEG nor GIF image formats consist of >> ASCII text with end of line markers. An image on the hard disk of a >> computer is what an image is. What transmission formats are used by the >> HTML and WWW has nothing to do with what images "are". >> >> Of course, converting binaries to a format which transmits only 6 bits >> per character is a huge waste of bandwidth, which shows that there is >> room for improvement in those protocols. > > Since the example was web browsers above, the protocol is HTTP, and it > doesn't use base64. It's designed so that you can feed the image file > as-is over the protocol. See: Transfer-Encoding: chunked -- Using UNIX since v6 (1975)... Use the BIG mirror service in the UK: http://www.mirrorservice.org
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web