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 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2020-04-19 10:47 -0700 |
| Message-ID | <423615084.609010733.750837.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #211060 |
J. Clarke <jclarke.873638@gmail.com> wrote: > On 19 Apr 2020 08:55:31 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se> > wrote: > >> On Sat, 2020-04-18, J Clarke wrote: >>> On Sat, 18 Apr 2020 22:22:36 -0000 (UTC), John Levine >>> <johnl@taugh.com> wrote: >>> >>>> In article >>>> <174465144.608927440.165750.peter_flass-yahoo.com@news.eternal-september.org>, >>>> >>>> Peter Flass <peter_flass@yahoo.com> wrote: >>>>> If line breaks are not significant, why not include them so the file will >>>>> be human-readable. Sometime you want to look at this stuff to debug >>>>> something. >>>> >>>> Because we don't know how big the screens or windows are on which >>>> we'll be looking at them. Computers are really good at wrapping text >>>> on the fly. >>> >>> I think that this is something that people who have managed somehow to >>> stick their mindset into the 80x25 mindset don't get. Right now I'm >>> using a 49 inch 8 megapixel display. At work I typically use two two >>> megapixel 21 inch displayes. And it is possible to buy from a mass >>> market vendor a 75 inch 16 megapixel display. The same web site has >>> to work on all of those, and on a cell phone, and on a laptop, and on >>> a tablet. This means that formatting has to be quite flexible. >> >> It's still a fact that it's hard to read text wider than 60--70 >> characters; computers can't fix that. > > Do you have research to support that statement? >> >> /Jorgen > I’m sure there is some. I’d like to see it. If i get time I’ll search. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Ahem A Rivet's Shot <steveo@eircom.net> |
|---|---|
| Date | 2020-04-13 19:54 +0100 |
| Message-ID | <20200413195424.4c6df8fbc4afcb2aedff4c0b@eircom.net> |
| In reply to | #210928 |
On Sun, 12 Apr 2020 22:11:41 -0700 (PDT) Quadibloc <jsavard@ecn.ab.ca> wrote: > 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). Typically a text file is a bunch of characters usually including line terminators, not a bunch of strings of any type. -- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
[toc] | [prev] | [next] | [standalone]
| From | hancock4@bbs.cpcn.com |
|---|---|
| Date | 2020-08-22 11:18 -0700 |
| Message-ID | <fdbaac91-9230-4837-8944-3020cb027919o@googlegroups.com> |
| In reply to | #210928 |
On Monday, April 13, 2020 at 1:11:42 AM UTC-4, Quadibloc wrote: > 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. When time sharing came along, different systems had different protocols for the user to signal end-of-line and the computer to indicate it was ready for the next line. A common one was the user hit CR and the system responded with LF when ready. But not always, sometimes the opposite, sometimes x-on and x-off were utilized to facilitate paper tape input.
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2020-04-14 05:24 +0200 |
| Message-ID | <51nfmg-7bd.ln1@Telcontar.valinor> |
| In reply to | #210897 |
On 12/04/2020 12.59, Gareth Evans wrote: > Both CR and LF are command characters that reflect the > mechanical make-up of some printing devices, the > ASR / KSR 33 / 35 perhaps being the most common at > the time of the creation of the code. > > But where there are those who argue that device > characteristics should be hidden away in the > device drivers and not be embedded in printable > text, should not the end of a line be marked by ETX > and the end of a file by EOT and not ^Z? You are confusing the behaviour of complex printer drivers with plain simple text printers (with no drivers). -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Ahem A Rivet's Shot <steveo@eircom.net> |
|---|---|
| Date | 2020-04-18 08:44 +0100 |
| Message-ID | <20200418084448.4309165204a9653445cd75fc@eircom.net> |
| In reply to | #210952 |
On Tue, 14 Apr 2020 05:24:53 +0200 "Carlos E.R." <robin_listas@es.invalid> wrote: > You are confusing the behaviour of complex printer drivers with plain > simple text printers (with no drivers). Plain simple text printers usually do have drivers, they're just very simple and support an extremely wide range of printers. They can usually be configured to handle CR/LF/CRLF translations as well as inserting NULs and/or delays to accommodate hardware restrictions. The unix tty driver is a good example. -- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2020-04-18 12:08 +0200 |
| Message-ID | <n50rmg-i9g.ln1@Telcontar.valinor> |
| In reply to | #211010 |
On 18/04/2020 09.44, Ahem A Rivet's Shot wrote: > On Tue, 14 Apr 2020 05:24:53 +0200 > "Carlos E.R." <robin_listas@es.invalid> wrote: > >> You are confusing the behaviour of complex printer drivers with plain >> simple text printers (with no drivers). > > Plain simple text printers usually do have drivers, they're just > very simple and support an extremely wide range of printers. They can > usually be configured to handle CR/LF/CRLF translations as well as > inserting NULs and/or delays to accommodate hardware restrictions. The unix > tty driver is a good example. I used my 9 pin printers in MsDOS directly, file copy to printer port. No driver at all. Worked perfectly. :-) I have done the same from unix, but via rs232 port. Had to flip a switch in the printer to handle cr/lf. -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | Ahem A Rivet's Shot <steveo@eircom.net> |
|---|---|
| Date | 2020-04-18 12:02 +0100 |
| Message-ID | <20200418120248.dd0c5d11b0a61de54f7c041d@eircom.net> |
| In reply to | #211015 |
On Sat, 18 Apr 2020 12:08:23 +0200 "Carlos E.R." <robin_listas@es.invalid> wrote: > On 18/04/2020 09.44, Ahem A Rivet's Shot wrote: > > On Tue, 14 Apr 2020 05:24:53 +0200 > > "Carlos E.R." <robin_listas@es.invalid> wrote: > > > >> You are confusing the behaviour of complex printer drivers with plain > >> simple text printers (with no drivers). > > > > Plain simple text printers usually do have drivers, they're just > > very simple and support an extremely wide range of printers. They can > > usually be configured to handle CR/LF/CRLF translations as well as > > inserting NULs and/or delays to accommodate hardware restrictions. The > > unix tty driver is a good example. > > I used my 9 pin printers in MsDOS directly, file copy to printer port. > No driver at all. Worked perfectly. :-) There's a driver, it's built into MSDOS, it drives the printer port, I don't think it can do any conversions BICBW it's been a long time since MSDOS. > I have done the same from unix, but via rs232 port. Had to flip a switch > in the printer to handle cr/lf. The unix tty driver is quite capable of handling the cr/lf conversions (and a great deal more) - see man stty for details. You could have configured the driver instead of flipping the switch. Just because it isn't model specific doesn't mean it isn't a driver, all devices have drivers. -- Steve O'Hara-Smith | Directable Mirror Arrays C:\>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
[toc] | [prev] | [next] | [standalone]
| From | "Carlos E.R." <robin_listas@es.invalid> |
|---|---|
| Date | 2020-04-18 21:50 +0200 |
| Message-ID | <l82smg-ba6.ln1@Telcontar.valinor> |
| In reply to | #211017 |
On 18/04/2020 13.02, Ahem A Rivet's Shot wrote: > On Sat, 18 Apr 2020 12:08:23 +0200 > "Carlos E.R." <robin_listas@es.invalid> wrote: > >> On 18/04/2020 09.44, Ahem A Rivet's Shot wrote: >>> On Tue, 14 Apr 2020 05:24:53 +0200 >>> "Carlos E.R." <robin_listas@es.invalid> wrote: >>> >>>> You are confusing the behaviour of complex printer drivers with plain >>>> simple text printers (with no drivers). >>> >>> Plain simple text printers usually do have drivers, they're just >>> very simple and support an extremely wide range of printers. They can >>> usually be configured to handle CR/LF/CRLF translations as well as >>> inserting NULs and/or delays to accommodate hardware restrictions. The >>> unix tty driver is a good example. >> >> I used my 9 pin printers in MsDOS directly, file copy to printer port. >> No driver at all. Worked perfectly. :-) > > There's a driver, it's built into MSDOS, it drives the printer port, > I don't think it can do any conversions BICBW it's been a long time since > MSDOS. I don't call that "a driver". I also printed from my own code handling directly the port chip. In any case, I assure you there was no modification of the stream the code sends and what the printer gets, byte by byte. I could use a library, that simply allowed me to send a string to the printer and not having to care about the gore details of the assembler code that handled the chip. This could be called "driver" at the time, but did no translation at all. It just took a byte, wrote it to the output port when ready, detected when the port was ready for the next char, and sent it, till buffer was empty. Any conversion had to be done by your program code. Like a font change. Writing a graphic was very entertaining. > >> I have done the same from unix, but via rs232 port. Had to flip a switch >> in the printer to handle cr/lf. > > The unix tty driver is quite capable of handling the cr/lf > conversions (and a great deal more) - see man stty for details. You could > have configured the driver instead of flipping the switch. Ha! It was far easier to flip a switch (including reading the manual) than finding if it was possible to do the equivalent in that unix machine. Even support said to configure the printer. > Just because it isn't model specific doesn't mean it isn't a > driver, all devices have drivers. > -- Cheers, Carlos.
[toc] | [prev] | [next] | [standalone]
| From | usenet@only.tnx (Questor) |
|---|---|
| Date | 2020-04-18 03:40 +0000 |
| Message-ID | <5e9a75a3.856491@news.dslextreme.com> |
| In reply to | #210897 |
"We are the programmers who now terminate our text file lines with ekky-ekky-ekky-ekky-p'tang-zoom-boing!-mrowrrr." -- the programmers who formerly terminated their text file lines with CRLF I've seen "religious" wars over operating systems, languages, and editors, but over text file line terminators? Who would have guessed? Some people in this discussion are conflating printers and terminals, and there is a salient distinction to be made there. Given the context of the times and the number of printing/paper terminals in use then, it is entirely reasonable that text file lines be terminated with a CRLF pair, so that a file that was TYPEd would display correctly on a terminal without any implicit processing by the operating system. As others have noted, it also allows for overstriking. The other appropriate control characters -- tab, vertical tab, form feed (AKA page throw), and bell -- had their expected effect as well. In the days when I was slinging code on PDP10s, it was common practice for programs to accept CR, LF, CRLF, VT, FF, and ESC as signifying the end of a user's line of input. This behavior was emulated by video terminals (AKA glass ttys). A bare CR would return the cursor to the beginning of the line without moving to the next line; a bare LF would move the cursor to the next line but not horizontally. I relied on this when I wrote a little joke program that would display the lines of a text file from right to left instead of left to right, and it worked on both printing and video terminals. I once had a customer problem that involved line terminators. This user had a COBOL program on a PDP10 (I can't remember if it was TOPS10 or TOPS20, but no matter) that generated a report -- a text file. The file was transfered over DECnet to a VAX, where it would be printed. The problem was that when the file was printed, all the blank line spacing was doubled. If there was supposed to be one blank line there were two, if there was supposed to be two blank lines there were four, etc. I don't know COBOL, but the problem arose due to how the "advancing" clause used in the program's print statements was implemented. The COBOL runtime system would terminate the first line with a CRLF, and then output the appropriate number of bare LFs to create the desired number of blank lines. VMS has what I would call a very aggressive record management system (RMS). When the file was transfered to the VAX, the RMS somehow recognized the LFs as being separate lines, but put them each in their own record. So when the file was printed, it would output the bare LF from the record, and then, because it was a text file and according to the RMS each record in a text file is terminated by a CRLF, it would send that as well. Changing the PDP10 COBOL runtime system was out of the question, as its behavior was long-established and perhaps relied on by other programs. Changing the VMS RMS was also a non-starter. I offered a couple of work-arounds, the details of which are long forgotten. One of them was to use the appropriate VMS command to change the RMS properties of the transferred file. I think there may have also been a switch to NFT (the DECnet Network File Transfer utility) that caused the file to be received by the VAX as a type that would print as desired.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2020-05-23 03:40 -0700 |
| Message-ID | <c40f7000-bdbb-42c9-bc02-5997f90cf388@googlegroups.com> |
| In reply to | #211009 |
On Friday, April 17, 2020 at 9:40:07 PM UTC-6, Questor wrote: > In the days when I > was slinging code on PDP10s, it was common practice for programs to accept CR, > LF, CRLF, VT, FF, and ESC as signifying the end of a user's line of input. That is so strange. Whatever the operating system may accept as signifying the end of a user's line of input, by the time that line of input gets to an applications program, the operating system should signal the end of that line in one and only one unique way - and so programs would handle exactly that way and no other to work properly. John Savard
[toc] | [prev] | [next] | [standalone]
| From | J. Clarke <jclarke.873638@gmail.com> |
|---|---|
| Date | 2020-05-23 08:38 -0400 |
| Message-ID | <576icf94md9shna5jsfc8up63rdkb9paro@4ax.com> |
| In reply to | #211554 |
On Sat, 23 May 2020 03:40:25 -0700 (PDT), Quadibloc <jsavard@ecn.ab.ca> wrote: >On Friday, April 17, 2020 at 9:40:07 PM UTC-6, Questor wrote: >> In the days when I >> was slinging code on PDP10s, it was common practice for programs to accept CR, >> LF, CRLF, VT, FF, and ESC as signifying the end of a user's line of input. > >That is so strange. Whatever the operating system may accept as signifying the end >of a user's line of input, by the time that line of input gets to an applications >program, the operating system should signal the end of that line in one and only >one unique way - and so programs would handle exactly that way and no other to >work properly. Why is that the responsibility of the operating system? All it is obligated to do is furnish bytes until the end of data has been reached. If it starts changing characters it can make a huge mess.
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2020-05-23 08:02 -0700 |
| Message-ID | <e219bf14-abd0-4787-8cdb-09909f618d6e@googlegroups.com> |
| In reply to | #211557 |
On Saturday, May 23, 2020 at 6:38:32 AM UTC-6, J. Clarke wrote: > On Sat, 23 May 2020 03:40:25 -0700 (PDT), Quadibloc > <jsavard@ecn.ab.ca> wrote: > >On Friday, April 17, 2020 at 9:40:07 PM UTC-6, Questor wrote: > >> In the days when I > >> was slinging code on PDP10s, it was common practice for programs to accept CR, > >> LF, CRLF, VT, FF, and ESC as signifying the end of a user's line of input. > > > >That is so strange. Whatever the operating system may accept as signifying the end > >of a user's line of input, by the time that line of input gets to an applications > >program, the operating system should signal the end of that line in one and only > >one unique way - and so programs would handle exactly that way and no other to > >work properly. > Why is that the responsibility of the operating system? All it is > obligated to do is furnish bytes until the end of data has been > reached. If it starts changing characters it can make a huge mess. The PDP-10 operating system may indeed be more similar to UNIX than it is to OS/360, so perhaps my comment was sufficiently unclear as to admit confusion. It is true that under some circumstances, a user program may request characters from a device of an appropriate kind, and in such a case, one wouldn't want the operating system to change what characters are recieved. However, I was thinking that in the more common case, a user program will request *records* from a device. While those records might be delimited by ASCII (or EBCDIC) characters if the device was a character mode terminal or a paper- tape reader, they would _not_ be delimited by any such thing on a magnetic tape drive (either inter-record gaps, or the block structure), a punched-card reader, *or* a disk drive (because the disk files wouldn't look like what they do in UNIX - records on the disk would look like Pascal strings do, and they also might be in an ISAM file structure). And then there are block mode terminals. Some ASCII ones do fake behaving like ASCII character-mode terminals, because that's what the things they're connected to are used to. The 3277 display station, for example, doesn't do stuff like that. John Savard
[toc] | [prev] | [next] | [standalone]
| From | J. Clarke <jclarke.873638@gmail.com> |
|---|---|
| Date | 2020-05-23 11:07 -0400 |
| Message-ID | <rueicf1htibqa6fk68fgmqk30roa5qsesu@4ax.com> |
| In reply to | #211559 |
On Sat, 23 May 2020 08:02:49 -0700 (PDT), Quadibloc <jsavard@ecn.ab.ca> wrote: >On Saturday, May 23, 2020 at 6:38:32 AM UTC-6, J. Clarke wrote: >> On Sat, 23 May 2020 03:40:25 -0700 (PDT), Quadibloc >> <jsavard@ecn.ab.ca> wrote: >> >On Friday, April 17, 2020 at 9:40:07 PM UTC-6, Questor wrote: > >> >> In the days when I >> >> was slinging code on PDP10s, it was common practice for programs to accept CR, >> >> LF, CRLF, VT, FF, and ESC as signifying the end of a user's line of input. >> > >> >That is so strange. Whatever the operating system may accept as signifying the end >> >of a user's line of input, by the time that line of input gets to an applications >> >program, the operating system should signal the end of that line in one and only >> >one unique way - and so programs would handle exactly that way and no other to >> >work properly. > >> Why is that the responsibility of the operating system? All it is >> obligated to do is furnish bytes until the end of data has been >> reached. If it starts changing characters it can make a huge mess. > >The PDP-10 operating system may indeed be more similar to UNIX than it is to >OS/360, so perhaps my comment was sufficiently unclear as to admit confusion. > >It is true that under some circumstances, a user program may request characters >from a device of an appropriate kind, and in such a case, one wouldn't want the >operating system to change what characters are recieved. > >However, I was thinking that in the more common case, a user program will >request *records* from a device. While those records might be delimited by ASCII >(or EBCDIC) characters if the device was a character mode terminal or a paper- >tape reader, they would _not_ be delimited by any such thing on a magnetic tape >drive (either inter-record gaps, or the block structure), a punched-card reader, >*or* a disk drive (because the disk files wouldn't look like what they do in >UNIX - records on the disk would look like Pascal strings do, and they also >might be in an ISAM file structure). > >And then there are block mode terminals. Some ASCII ones do fake behaving like >ASCII character-mode terminals, because that's what the things they're connected >to are used to. The 3277 display station, for example, doesn't do stuff like >that. If the convention is that there are 20 different characters any of which can be used as end-of-record, again it is not the operating system's responsibility to change them. If I write a program that generates records with some specific character as end of record and the operating system changes that then when my program tries to read its own records that it generated it breaks. See the problem?
[toc] | [prev] | [next] | [standalone]
| From | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2020-05-23 11:27 -0700 |
| Message-ID | <34136f77-1948-4b80-8b25-952c1e2b7037@googlegroups.com> |
| In reply to | #211560 |
On Saturday, May 23, 2020 at 9:07:37 AM UTC-6, J. Clarke wrote: > See the problem? Certainly, during charater mode I/O, the operating system should not modify characters. My point was, when you said: > Why is that the responsibility of the operating system? All it is > obligated to do is furnish bytes until the end of data has been > reached. you're thinking of a different kind of operating system than I was. I was thinking of operating sytems which don't deal much in character mode I/O, because it's inefficient to go through the layers from application program to operating system to device driver that often. Instead, the fundamental unit is the record. A call is made to read a line of text from a device - and different devices each have their own way of marking the end of a line of text, many of which don't even *involve* characters. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2020-05-23 12:27 -0700 |
| Message-ID | <2093984810.611954571.231978.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #211560 |
J. Clarke <jclarke.873638@gmail.com> wrote: > On Sat, 23 May 2020 08:02:49 -0700 (PDT), Quadibloc > <jsavard@ecn.ab.ca> wrote: > >> On Saturday, May 23, 2020 at 6:38:32 AM UTC-6, J. Clarke wrote: >>> On Sat, 23 May 2020 03:40:25 -0700 (PDT), Quadibloc >>> <jsavard@ecn.ab.ca> wrote: >>>> On Friday, April 17, 2020 at 9:40:07 PM UTC-6, Questor wrote: >> >>>>> In the days when I >>>>> was slinging code on PDP10s, it was common practice for programs to accept CR, >>>>> LF, CRLF, VT, FF, and ESC as signifying the end of a user's line of input. >>>> >>>> That is so strange. Whatever the operating system may accept as signifying the end >>>> of a user's line of input, by the time that line of input gets to an applications >>>> program, the operating system should signal the end of that line in one and only >>>> one unique way - and so programs would handle exactly that way and no other to >>>> work properly. >> >>> Why is that the responsibility of the operating system? All it is >>> obligated to do is furnish bytes until the end of data has been >>> reached. If it starts changing characters it can make a huge mess. >> >> The PDP-10 operating system may indeed be more similar to UNIX than it is to >> OS/360, so perhaps my comment was sufficiently unclear as to admit confusion. >> >> It is true that under some circumstances, a user program may request characters >> from a device of an appropriate kind, and in such a case, one wouldn't want the >> operating system to change what characters are recieved. >> >> However, I was thinking that in the more common case, a user program will >> request *records* from a device. While those records might be delimited by ASCII >> (or EBCDIC) characters if the device was a character mode terminal or a paper- >> tape reader, they would _not_ be delimited by any such thing on a magnetic tape >> drive (either inter-record gaps, or the block structure), a punched-card reader, >> *or* a disk drive (because the disk files wouldn't look like what they do in >> UNIX - records on the disk would look like Pascal strings do, and they also >> might be in an ISAM file structure). >> >> And then there are block mode terminals. Some ASCII ones do fake behaving like >> ASCII character-mode terminals, because that's what the things they're connected >> to are used to. The 3277 display station, for example, doesn't do stuff like >> that. > > If the convention is that there are 20 different characters any of > which can be used as end-of-record, again it is not the operating > system's responsibility to change them. If I write a program that > generates records with some specific character as end of record and > the operating system changes that then when my program tries to read > its own records that it generated it breaks. > > See the problem? > Systems, including AFAIK Unix and Multics have the ability to return a record “as is” or what Multics calls “canonical” format. For example, if the user types “abd<bs>c” do you want to see five characters or three? -- Pete
[toc] | [prev] | [next] | [standalone]
| From | J. Clarke <jclarke.873638@gmail.com> |
|---|---|
| Date | 2020-05-23 18:21 -0400 |
| Message-ID | <i98jcf535slvsvcfnlod7b84s0uvidog7l@4ax.com> |
| In reply to | #211563 |
On Sat, 23 May 2020 12:27:14 -0700, Peter Flass <peter_flass@yahoo.com> wrote: >J. Clarke <jclarke.873638@gmail.com> wrote: >> On Sat, 23 May 2020 08:02:49 -0700 (PDT), Quadibloc >> <jsavard@ecn.ab.ca> wrote: >> >>> On Saturday, May 23, 2020 at 6:38:32 AM UTC-6, J. Clarke wrote: >>>> On Sat, 23 May 2020 03:40:25 -0700 (PDT), Quadibloc >>>> <jsavard@ecn.ab.ca> wrote: >>>>> On Friday, April 17, 2020 at 9:40:07 PM UTC-6, Questor wrote: >>> >>>>>> In the days when I >>>>>> was slinging code on PDP10s, it was common practice for programs to accept CR, >>>>>> LF, CRLF, VT, FF, and ESC as signifying the end of a user's line of input. >>>>> >>>>> That is so strange. Whatever the operating system may accept as signifying the end >>>>> of a user's line of input, by the time that line of input gets to an applications >>>>> program, the operating system should signal the end of that line in one and only >>>>> one unique way - and so programs would handle exactly that way and no other to >>>>> work properly. >>> >>>> Why is that the responsibility of the operating system? All it is >>>> obligated to do is furnish bytes until the end of data has been >>>> reached. If it starts changing characters it can make a huge mess. >>> >>> The PDP-10 operating system may indeed be more similar to UNIX than it is to >>> OS/360, so perhaps my comment was sufficiently unclear as to admit confusion. >>> >>> It is true that under some circumstances, a user program may request characters >>> from a device of an appropriate kind, and in such a case, one wouldn't want the >>> operating system to change what characters are recieved. >>> >>> However, I was thinking that in the more common case, a user program will >>> request *records* from a device. While those records might be delimited by ASCII >>> (or EBCDIC) characters if the device was a character mode terminal or a paper- >>> tape reader, they would _not_ be delimited by any such thing on a magnetic tape >>> drive (either inter-record gaps, or the block structure), a punched-card reader, >>> *or* a disk drive (because the disk files wouldn't look like what they do in >>> UNIX - records on the disk would look like Pascal strings do, and they also >>> might be in an ISAM file structure). >>> >>> And then there are block mode terminals. Some ASCII ones do fake behaving like >>> ASCII character-mode terminals, because that's what the things they're connected >>> to are used to. The 3277 display station, for example, doesn't do stuff like >>> that. >> >> If the convention is that there are 20 different characters any of >> which can be used as end-of-record, again it is not the operating >> system's responsibility to change them. If I write a program that >> generates records with some specific character as end of record and >> the operating system changes that then when my program tries to read >> its own records that it generated it breaks. >> >> See the problem? >> > >Systems, including AFAIK Unix and Multics have the ability to return a >record “as is” or what Multics calls “canonical” format. For example, if >the user types “abd<bs>c” do you want to see five characters or three? What am "I"? If I am APL I want two characters separated by a backspace to be mapped to an overstruck APL character if there is one that matches that combination, for example.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2020-05-23 20:10 +0000 |
| Message-ID | <rabvvu$dsc$1@gal.iecc.com> |
| In reply to | #211559 |
In article <e219bf14-abd0-4787-8cdb-09909f618d6e@googlegroups.com>, Quadibloc <jsavard@ecn.ab.ca> wrote: >However, I was thinking that in the more common case, a user program will >request *records* from a device. ... TOPS-10 handled block devices like DECtape and disks perfectly well and did reads and writes directly from buffers in the user address space sort of like IBM mainframe QSAM. But the most common way to use them was as a stream of bytes ignoring the physical block boundaries. The usual line terminator was CR+LF, and null bytes in files were generally ignored as padding. For text files, the standard kludge was the each line started on a word boundary with five ASCII digits followed by a tab, with the otherwise unused low bit of the word with the digits set to indicate that it was a line number of interest to text editors but generally ignored by other programs. -- 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 | Quadibloc <jsavard@ecn.ab.ca> |
|---|---|
| Date | 2020-05-24 08:32 -0700 |
| Message-ID | <85f8db34-31c4-4e84-ac08-318f3d04364c@googlegroups.com> |
| In reply to | #211565 |
On Saturday, May 23, 2020 at 2:10:39 PM UTC-6, John Levine wrote: > In article <e219bf14-abd0-4787-8cdb-09909f618d6e@googlegroups.com>, > Quadibloc <jsavard@ecn.ab.ca> wrote: > >However, I was thinking that in the more common case, a user program will > >request *records* from a device. ... > > TOPS-10 handled block devices like DECtape and disks perfectly well > and did reads and writes directly from buffers in the user address > space sort of like IBM mainframe QSAM. But the most common way to use > them was as a stream of bytes ignoring the physical block boundaries. > > The usual line terminator was CR+LF, and null bytes in files were > generally ignored as padding. For text files, the standard kludge was > the each line started on a word boundary with five ASCII digits > followed by a tab, with the otherwise unused low bit of the word with > the digits set to indicate that it was a line number of interest to > text editors but generally ignored by other programs. As the tab is in the next word, it would have to be stripped out... And what I'm used to is the Michigan Terminal System. Text files are normally line files. The format of a line file is: An ISAM file with two fields. One field is a 32-bit integer. That field is the primary key, and it is the line number. It is in units of 0.001, so a file with lines numbered 1, 2, 3, and 4 would have the integer values 1000, 2000, 3000 and 4000 in this field. (This facilitates line insertion in text editors.) The other field is a variable-length text field. This contains the line of text itself. It may be from 0 to 255 characters in length. (This was changed to 0 to 32,767 in a later version of the operating system.) The text field could contain *any* data, including binary data. The characters in it were only data and didn't delimit records - that was done out of band. One text field = one record. So mixing binary data and text was no problem. This worked so well and was so easy to use and understand that I'm shocked that today's microcomputers instead expose the user to messiness that can lead to buffer overflow problems and the like. John Savard
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2020-05-24 16:25 +0000 |
| Message-ID | <rae75t019dh@news2.newsguy.com> |
| In reply to | #211574 |
On 2020-05-24, Quadibloc <jsavard@ecn.ab.ca> wrote:
> And what I'm used to is the Michigan Terminal System.
>
> Text files are normally line files.
>
> The format of a line file is:
>
> An ISAM file with two fields.
>
> One field is a 32-bit integer. That field is the primary key, and it is the
> line number. It is in units of 0.001, so a file with lines numbered 1, 2, 3,
> and 4 would have the integer values 1000, 2000, 3000 and 4000 in this field.
> (This facilitates line insertion in text editors.)
>
> The other field is a variable-length text field. This contains the line of
> text itself. It may be from 0 to 255 characters in length. (This was changed
> to 0 to 32,767 in a later version of the operating system.)
>
> The text field could contain *any* data, including binary data. The
> characters in it were only data and didn't delimit records - that was
> done out of band. One text field = one record. So mixing binary data and
> text was no problem.
>
> This worked so well and was so easy to use and understand that I'm shocked
> that today's microcomputers instead expose the user to messiness that can
> lead to buffer overflow problems and the like.
It's a matter of parallel evolution. File systems like your MTS example
("Bright college days, oh, carefree days that fly..." -- Tom Lehrer)
were born on mainframe systems that had lots of buffering capability and
processing power. ASCII text files were born on Teletype networks which
had very little processing capability and even less buffering. Given the
constraints of the time, I'd say that each system served its purposes well.
ASCII text files are so much simpler that their limitations are often not
a serious factor - e.g., when transmitting text.
That DLE character mentioned upthread stands for "Data Link Escape",
and it shows that the designers of those Teletype networks were
thinking about the problem.
--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
[toc] | [prev] | [next] | [standalone]
| From | John Levine <johnl@taugh.com> |
|---|---|
| Date | 2020-05-24 18:29 +0000 |
| Message-ID | <raeedf$7dm$1@gal.iecc.com> |
| In reply to | #211575 |
In article <rae75t019dh@news2.newsguy.com>,
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>On 2020-05-24, Quadibloc <jsavard@ecn.ab.ca> wrote:
>
>> And what I'm used to is the Michigan Terminal System.
>>
>> Text files are normally line files.
>>
>> The format of a line file is:
>>
>> An ISAM file with two fields.
Yeah, TSS VISAM files were sort of like that, too.
>It's a matter of parallel evolution. File systems like your MTS example
>("Bright college days, oh, carefree days that fly..." -- Tom Lehrer)
>were born on mainframe systems that had lots of buffering capability and
>processing power. ASCII text files were born on Teletype networks which
>had very little processing capability and even less buffering. Given the
>constraints of the time, I'd say that each system served its purposes well.
>ASCII text files are so much simpler that their limitations are often not
>a serious factor - e.g., when transmitting text.
Quite right. IBM mainframes have I/O channels that can only do block
I/O. The only way to attach terminals is via front end systems that
handle the individual characters and turn them into blocks to send to
and from the channel.
The PDP-10 was an overgrown minicomputer that shared the same priority
interupt and word I/O features with its 18 bit relatives like the
PDP-4, 7, and -9. That made it able to do its own character at a time
I/O and also made it good at realtime applications without extra
kludgery like the 360/44 needed.
--
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]
Page 5 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