I had *.clients.your-server.de crawling mcvoy.com in violation of my robots.txt. For whatever reason, the tty settings (or something) made vi not work, I dunno what the deal is, stty -tabs didn't help. So I had to resort to ed to write and debug the little program below. It was surprisingly pleasant, it's probably the first time I've used ed for anything real in at least a decade. My fingers still know it. +1 for ed. It's how many decades old and still useful? #!/usr/libexec/bitkeeper/bk tclsh int main(void) { FILE log = popen("/var/log/apache2/dns.l", "r"); string buf, ip; string dropped{string}; fconfigure(log, buffering: "line"); while (buf = <log>) { unless (buf =~ /([^ ]+\.your-server\.de\.) /) continue; ip = $1; if (defined(dropped{ip})) continue; dropped{ip} = "yes"; warn("DROP ${ip}\n"); system("/sbin/iptables -I INPUT -s ${ip} -j DROP"); } }
* Larry McVoy <lm@mcvoy.com> [2021-03-29 07:34:49 -0700]: >I had *.clients.your-server.de crawling mcvoy.com in violation of my >robots.txt. For whatever reason, the tty settings (or something) >made vi not work, I dunno what the deal is, stty -tabs didn't help. > >So I had to resort to ed to write and debug the little program below. >It was surprisingly pleasant, it's probably the first time I've used ed >for anything real in at least a decade. My fingers still know it. > >+1 for ed. It's how many decades old and still useful? I recently learned ed(1) for the first time (I have a unix beard, but it's not grey yet). I found ed to be very efficient and useful for small fixes, even on slow connections. This beginner's tutorial was very helpful for me: gopher://katolaz.net/0/ed_tutorial.txt (https mirror for non-gopher clients: https://adamsgaard.dk/npub/ed_tutorial.txt )
From 1984, when I stopped using vi (vee eye), until the early 1990's, when
I could use Sam, I used a slightly hacked version of ed. I added
what the Labs called the "b" command. I had use some other character. Dennis
Ritchie sent me a 8th Edition Unix manual, and I saw they had added almost
the same thing and called the command by the second letter. Vi called
it the last letter, "z."
I've never found ed slows me down. Some things I would have used awk/sed
for that I now use Sam's command window for, but that's a bad thing. I still
use ed a lot along side Sam.
> On Mar 29, 2021, at 11:09 AM, Anders Damsgaard <anders@adamsgaard.dk> wrote:
>
> * Larry McVoy <lm@mcvoy.com> [2021-03-29 07:34:49 -0700]:
>
>> I had *.clients.your-server.de crawling mcvoy.com in violation of my
>> robots.txt. For whatever reason, the tty settings (or something)
>> made vi not work, I dunno what the deal is, stty -tabs didn't help.
>>
>> So I had to resort to ed to write and debug the little program below.
>> It was surprisingly pleasant, it's probably the first time I've used ed
>> for anything real in at least a decade. My fingers still know it.
>>
>> +1 for ed. It's how many decades old and still useful?
>
> I recently learned ed(1) for the first time (I have a unix beard, but it's
> not grey yet). I found ed to be very efficient and useful for small fixes,
> even on slow connections. This beginner's tutorial was very helpful
> for me: gopher://katolaz.net/0/ed_tutorial.txt
>
> (https mirror for non-gopher clients:
> https://adamsgaard.dk/npub/ed_tutorial.txt )
On Mon, 29 Mar 2021 at 17:27, Brantley Coile <brantley@coraid.com> wrote:
>Some things I would have used awk/sed
> for that I now use Sam's command window for, but that's a bad thing.
Why is that a bad thing? (Informative question.)
Mark.
[-- Attachment #1: Type: text/plain, Size: 2600 bytes --] Anders -- good for you. That said, as one of those 'grey beards,' can I recommend that you stop, and go to a technical library or bookstore and find yourself a copy of Rob and Brian's wonderful book: "*The Unix Programming Environment*" (*a.k.a* "UPE" or ISBN 0-13-937699-2) *then do the exercises*. That book is still relevant today - a little secret, I give a copy of it and "*Advanced Programming in the Unix Environment*" (*a.k.a.* "APUE") to all my new engineers - even though they are all using 'Linux' for their work. To those that object at first, I remind them, Linux is just the current and most popular implementation of the ideas from Ken, Dennis, Doug, and friends and I'm sure they will learn something from the time invested[1]. FWIW: Besides learning ed (which will help you unlock some of the mysteries of other UNIX tools like grep and sed), take a shot at looking at the introduction to nroff/troff (as has been discussed here - not to restart a war). Learning to use a 'document compiler' like the troff family is never a bad investment. Have fun, Clem 1.] BTW I have yet had a young engineer that actually did try the exercises not come back and say something like "Wow, I never knew ...." I don't gloat, but I smile inside, know that I just made them a more effective for our team. If they ask, I point out I had been using UNIX and hacking on the kernel most every day for at least 10 years when it first appeared in the early 80's (84/85 I think), and I learned a few tricks when I read it. ᐧ ᐧ On Mon, Mar 29, 2021 at 11:16 AM Anders Damsgaard <anders@adamsgaard.dk> wrote: > * Larry McVoy <lm@mcvoy.com> [2021-03-29 07:34:49 -0700]: > > >I had *.clients.your-server.de crawling mcvoy.com in violation of my > >robots.txt. For whatever reason, the tty settings (or something) > >made vi not work, I dunno what the deal is, stty -tabs didn't help. > > > >So I had to resort to ed to write and debug the little program below. > >It was surprisingly pleasant, it's probably the first time I've used ed > >for anything real in at least a decade. My fingers still know it. > > > >+1 for ed. It's how many decades old and still useful? > > I recently learned ed(1) for the first time (I have a unix beard, but it's > not grey yet). I found ed to be very efficient and useful for small fixes, > even on slow connections. This beginner's tutorial was very helpful > for me: gopher://katolaz.net/0/ed_tutorial.txt > > (https mirror for non-gopher clients: > https://adamsgaard.dk/npub/ed_tutorial.txt ) > [-- Attachment #2: Type: text/html, Size: 4944 bytes --]
* Clem Cole <clemc@ccc.com> [2021-03-29 11:37:57 -0400]:
>Anders -- good for you.
>
>That said, as one of those 'grey beards,' can I recommend that you stop,
>and go to a technical library or bookstore and find yourself a copy of Rob
>and Brian's wonderful book: "*The Unix Programming Environment*" (*a.k.a*
>"UPE" or ISBN 0-13-937699-2) *then do the exercises*. That book is still
>relevant today - a little secret, I give a copy of it and "*Advanced
>Programming in the Unix Environment*" (*a.k.a.* "APUE") to all my new
>engineers - even though they are all using 'Linux' for their work. To
>those that object at first, I remind them, Linux is just the current and
>most popular implementation of the ideas from Ken, Dennis, Doug, and
>friends and I'm sure they will learn something from the time invested[1].
>
>FWIW: Besides learning ed (which will help you unlock some of the mysteries
>of other UNIX tools like grep and sed), take a shot at looking at the
>introduction to nroff/troff (as has been discussed here - not to restart a
>war). Learning to use a 'document compiler' like the troff family is never
>a bad investment.
>
>Have fun,
>Clem
>
>
>1.] BTW I have yet had a young engineer that actually did try the
>exercises not come back and say something like "Wow, I never knew ...." I
>don't gloat, but I smile inside, know that I just made them a more
>effective for our team. If they ask, I point out I had been using UNIX and
>hacking on the kernel most every day for at least 10 years when it first
>appeared in the early 80's (84/85 I think), and I learned a few tricks when
>I read it.
I appreciate the kind advice Clem! I'm dipping my toes into heirloom
doctools these days, and am delightened by the simplicity, modularity,
and speed compared to latex. However, much to learn still so thanks
for the nudge.
Anders
Typo.
Worry. Not a bad thing.
> On Mar 29, 2021, at 11:36 AM, Mark van Atten <vanattenmark@gmail.com> wrote:
>
> On Mon, 29 Mar 2021 at 17:27, Brantley Coile <brantley@coraid.com> wrote:
>> Some things I would have used awk/sed
>> for that I now use Sam's command window for, but that's a bad thing.
>
> Why is that a bad thing? (Informative question.)
>
> Mark.
On Monday, March 29, 2021, Brantley Coile <brantley@coraid.com> wrote:
>
> From 1984, when I stopped using vi (vee eye), until the early 1990's, when
> I could use Sam, I used a slightly hacked version of ed. I added
> what the Labs called the "b" command. I had use some other character. Dennis
> Ritchie sent me a 8th Edition Unix manual, and I saw they had added almost
> the same thing and called the command by the second letter. Vi called
> it the last letter, "z."
>
> I've never found ed slows me down. Some things I would have used awk/sed
> for that I now use Sam's command window for, but that's a bad thing. I still
> use ed a lot along side Sam.
>
If ed(1) had cursor positioning and full screen capabilities along
with line oriented editing (similar to Atari 8-bit default editor) it
would be perfect. I still love it though and use it pretty often.
--Andy
That's an excellent book. After that, try this one: https://www.amazon.com/Advanced-UNIX-Programming-Marc-Rochkind/dp/0131411543 On Mon, Mar 29, 2021 at 11:37:57AM -0400, Clem Cole wrote: > Anders -- good for you. > > That said, as one of those 'grey beards,' can I recommend that you stop, > and go to a technical library or bookstore and find yourself a copy of Rob > and Brian's wonderful book: "*The Unix Programming Environment*" (*a.k.a* > "UPE" or ISBN 0-13-937699-2) *then do the exercises*. That book is still > relevant today - a little secret, I give a copy of it and "*Advanced > Programming in the Unix Environment*" (*a.k.a.* "APUE") to all my new > engineers - even though they are all using 'Linux' for their work. To > those that object at first, I remind them, Linux is just the current and > most popular implementation of the ideas from Ken, Dennis, Doug, and > friends and I'm sure they will learn something from the time invested[1]. > > FWIW: Besides learning ed (which will help you unlock some of the mysteries > of other UNIX tools like grep and sed), take a shot at looking at the > introduction to nroff/troff (as has been discussed here - not to restart a > war). Learning to use a 'document compiler' like the troff family is never > a bad investment. > > Have fun, > Clem > > > 1.] BTW I have yet had a young engineer that actually did try the > exercises not come back and say something like "Wow, I never knew ...." I > don't gloat, but I smile inside, know that I just made them a more > effective for our team. If they ask, I point out I had been using UNIX and > hacking on the kernel most every day for at least 10 years when it first > appeared in the early 80's (84/85 I think), and I learned a few tricks when > I read it. > ??? > ??? > > On Mon, Mar 29, 2021 at 11:16 AM Anders Damsgaard <anders@adamsgaard.dk> > wrote: > > > * Larry McVoy <lm@mcvoy.com> [2021-03-29 07:34:49 -0700]: > > > > >I had *.clients.your-server.de crawling mcvoy.com in violation of my > > >robots.txt. For whatever reason, the tty settings (or something) > > >made vi not work, I dunno what the deal is, stty -tabs didn't help. > > > > > >So I had to resort to ed to write and debug the little program below. > > >It was surprisingly pleasant, it's probably the first time I've used ed > > >for anything real in at least a decade. My fingers still know it. > > > > > >+1 for ed. It's how many decades old and still useful? > > > > I recently learned ed(1) for the first time (I have a unix beard, but it's > > not grey yet). I found ed to be very efficient and useful for small fixes, > > even on slow connections. This beginner's tutorial was very helpful > > for me: gopher://katolaz.net/0/ed_tutorial.txt > > > > (https mirror for non-gopher clients: > > https://adamsgaard.dk/npub/ed_tutorial.txt ) > > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
[-- Attachment #1: Type: text/plain, Size: 2063 bytes --] Consider: Webb Miller's 's' - It been on my 'todo' list to get it running on 6th edition, but I admit that is low on my priority list. But I have run it on a couple of other 8-bit systems -- from the readme --- # s A tiny vi like screen editor Original sources were published in this book: Author: Webb Miller Title: A software tools sampler Publisher: Prentice-Hall, Inc. Upper Saddle River, NJ, USA ©1987 ISBN: 0-13-822305-X Martin, a guy from one of my hangouts named <c.o.cpm>, located the sources from this book. The repository starts from these original sources. Martin also provided the initial CP/M patches for compiling with HI-TECH C. Then the sources were overworked, to get it compiled without warnings on old systems with K&R C compiler, as well as modern systems with ANSI C compiler. This version of s is known to compile on: HI-TECH C for the Z80 under CP/M clang under OSX clang and gcc under Linux Mark Williams K&R C compiler under COHERENT ᐧ On Mon, Mar 29, 2021 at 11:46 AM Andy Kosela <akosela@andykosela.com> wrote: > On Monday, March 29, 2021, Brantley Coile <brantley@coraid.com> wrote: > > > > From 1984, when I stopped using vi (vee eye), until the early 1990's, > when > > I could use Sam, I used a slightly hacked version of ed. I added > > what the Labs called the "b" command. I had use some other character. > Dennis > > Ritchie sent me a 8th Edition Unix manual, and I saw they had added > almost > > the same thing and called the command by the second letter. Vi called > > it the last letter, "z." > > > > I've never found ed slows me down. Some things I would have used awk/sed > > for that I now use Sam's command window for, but that's a bad thing. I > still > > use ed a lot along side Sam. > > > > If ed(1) had cursor positioning and full screen capabilities along > with line oriented editing (similar to Atari 8-bit default editor) it > would be perfect. I still love it though and use it pretty often. > > --Andy > [-- Attachment #2: Type: text/html, Size: 3320 bytes --]
[-- Attachment #1: Type: text/plain, Size: 161 bytes --] On Mon, 29 Mar 2021, 5:43 pm Brantley Coile, <brantley@coraid.com> wrote: > Typo. > > Worry. Not a bad thing. > That's an informative answer ;) Thanks! Mark. [-- Attachment #2: Type: text/html, Size: 588 bytes --]
ed is the standard editor, they say. The b command (stands for browse) came from late-1970s U of T; rob probably brought it to 1127. There were a handful of other syntactic conveniences, like being allowed to leave off the final delimeter of an s command, and declaring that a missing address means 1 before the comma or semicolon and $ after, so 3,s/fish/&head works over all lines from 3 to the last, and , standing alone addresses the whole buffer. Also the idea that s followed by a digit N means start with the Nth instance of the pattern: s3/fish/&head/ affects only the third fish, and s3/fish/&head/g every fish after the second. I have all those tweaks, plus a few others, embedded in my fingers from the qed produced by the same Toronto hacks. I contracted it from the copy rob left behind at Caltech, which means it has been my editor of choice for 40 years now (with sam as an alternate favourite since its inception 35 years or so ago). That qed has a lot of cryptic programming stuff that I have mostly forgotten because it was never that useful, but what really hooked me was a. Multiple buffers, with the ability to move and copy text between them reasonably smoothly (both with the m and t commands and with an interpolate-into-input magic character); b. The > < | commands, which respectively send the addressed lines to a shell command (default ,), replace the addressed lines or append after the single addressed line the standard output of the shell command (default .), and replaced addressed lines with what you get by sending them (default ,) to the shell command, replacing them with its standard output. The last operators make qed into a kind of workbench, both for massaging data and for constructing a list of commands to send to the shell. I gather current Linux/BSD eds have > and <, spelled r ! and w !, but without | it just ain't the same, rather like the way | revolutionized the shell. I believe the credit for U of T ed and qed go mainly to Rob Pike, Tom Duff, Hugh Redelmeier, and the (alas now late) David Tillbrook. David remained an avid user of qed, continuing to add stuff to it. Norman Wilson Toronto ON PS: this message, as most of my e-mail, composed by typing it into qed, editing as needed, then running >mail tuhs@tuhs.org
On 3/29/21, Clem Cole <clemc@ccc.com> wrote:
> Anders -- good for you.
>
> That said, as one of those 'grey beards,' can I recommend that you stop,
> and go to a technical library or bookstore and find yourself a copy of Rob
> and Brian's wonderful book: "*The Unix Programming Environment*" (*a.k.a*
> "UPE" or ISBN 0-13-937699-2) *then do the exercises*. That book is still
> relevant today - a little secret, I give a copy of it and "*Advanced
> Programming in the Unix Environment*" (*a.k.a.* "APUE") to all my new
> engineers - even though they are all using 'Linux' for their work. To
> those that object at first, I remind them, Linux is just the current and
> most popular implementation of the ideas from Ken, Dennis, Doug, and
> friends and I'm sure they will learn something from the time invested[1].
+1. It is still my all time favorite Unix book, but the best ed(1)
tutorial I read has to be UNIX Programmer's Manual for Version 7.
Still highly recommended.
--Andy
On Mon, 29 Mar 2021, Larry McVoy wrote:
> I had *.clients.your-server.de crawling mcvoy.com in violation of my
> robots.txt. For whatever reason, the tty settings (or something)
> made vi not work, I dunno what the deal is, stty -tabs didn't help.
Hetzner. They're one of those cheap hosting providers (one of my servers
is hosted with them), and those types of providers are magnets for scum
because they're so cheap (OVH, which is the provider that hosted my mail
server for years, is particularly infamous).
-uso.
Andy Kosela <akosela@andykosela.com> wrote:
> If ed(1) had cursor positioning and full screen capabilities along
> with line oriented editing (similar to Atari 8-bit default editor) it
> would be perfect. I still love it though and use it pretty often.
Try out the 'se' editor, see www.se-editor.org.
Arnold
Clem Cole <clemc@ccc.com> writes:
> That said, as one of those 'grey beards,' can I recommend that you
> stop, and go to a technical library or bookstore and find yourself a
> copy of Rob and Brian's wonderful book: "*The Unix Programming
> Environment*" (*a.k.a* "UPE" or ISBN 0-13-937699-2) *then do the
> exercises*.
That is a great book - I'd been a Unix sysadmin for more than a decade
when I got it, and I learned a lot of new stuff from it. Twenty years
later, that book is still among my favorites, along with their newer
joint effort, "The Practice of Programming". Then there's the AWK book,
of course, and just about anything else with Brian Kernighan's name on
it. It's like with Date on database systems, or Stevens on networking;
you just know it's going to be good.
-tih
--
Most people who graduate with CS degrees don't understand the significance
of Lisp. Lisp is the most important idea in computer science. --Alan Kay
[-- Attachment #1: Type: text/plain, Size: 1179 bytes --] Ed is the standard editor. -rob On Tue, Mar 30, 2021 at 1:36 AM Larry McVoy <lm@mcvoy.com> wrote: > I had *.clients.your-server.de crawling mcvoy.com in violation of my > robots.txt. For whatever reason, the tty settings (or something) > made vi not work, I dunno what the deal is, stty -tabs didn't help. > > So I had to resort to ed to write and debug the little program below. > It was surprisingly pleasant, it's probably the first time I've used ed > for anything real in at least a decade. My fingers still know it. > > +1 for ed. It's how many decades old and still useful? > > > #!/usr/libexec/bitkeeper/bk tclsh > > int > main(void) > { > FILE log = popen("/var/log/apache2/dns.l", "r"); > string buf, ip; > string dropped{string}; > > fconfigure(log, buffering: "line"); > while (buf = <log>) { > unless (buf =~ /([^ ]+\.your-server\.de\.) /) continue; > ip = $1; > if (defined(dropped{ip})) continue; > dropped{ip} = "yes"; > warn("DROP ${ip}\n"); > system("/sbin/iptables -I INPUT -s ${ip} -j DROP"); > } > } > [-- Attachment #2: Type: text/html, Size: 1887 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1671 bytes --] I think you can only truly appreciate ed when you were forced to use a DECwriter as your terminal because all the VT100s were in use. (Undergrad student lab) — Michael Usher Network Operations Manager University of California, Santa Cruz musher@ucsc.edu 831-459-3697 > On Mar 29, 2021, at 12:50 PM, Rob Pike <robpike@gmail.com> wrote: > > Ed is the standard editor. > > -rob > > > On Tue, Mar 30, 2021 at 1:36 AM Larry McVoy <lm@mcvoy.com <mailto:lm@mcvoy.com>> wrote: > I had *.clients.your-server.de <http://clients.your-server.de/> crawling mcvoy.com <http://mcvoy.com/> in violation of my > robots.txt. For whatever reason, the tty settings (or something) > made vi not work, I dunno what the deal is, stty -tabs didn't help. > > So I had to resort to ed to write and debug the little program below. > It was surprisingly pleasant, it's probably the first time I've used ed > for anything real in at least a decade. My fingers still know it. > > +1 for ed. It's how many decades old and still useful? > > > #!/usr/libexec/bitkeeper/bk tclsh > > int > main(void) > { > FILE log = popen("/var/log/apache2/dns.l", "r"); > string buf, ip; > string dropped{string}; > > fconfigure(log, buffering: "line"); > while (buf = <log>) { > unless (buf =~ /([^ ]+\.your-server\.de\.) /) continue; > ip = $1; > if (defined(dropped{ip})) continue; > dropped{ip} = "yes"; > warn("DROP ${ip}\n"); > system("/sbin/iptables -I INPUT -s ${ip} -j DROP"); > } > } [-- Attachment #2: Type: text/html, Size: 5024 bytes --]
My high school had some computer, don't remember what, may have been a PDP 11. The *only* terminal was a line printer, probably a DECwriter, don't remember. I do remember it being about 130 columns. I don't remember if it was the real ed or a clone, but the editor was very similar to ed(1). And yes, it's the only way to go with a printer console. On Mon, Mar 29, 2021 at 01:50:55PM -0700, Michael Usher wrote: > I think you can only truly appreciate ed when you were forced to use a DECwriter as your terminal because all the VT100s were in use. (Undergrad student lab) > > > ??? > Michael Usher > Network Operations Manager > University of California, Santa Cruz > musher@ucsc.edu 831-459-3697 > > > On Mar 29, 2021, at 12:50 PM, Rob Pike <robpike@gmail.com> wrote: > > > > Ed is the standard editor. > > > > -rob > > > > > > On Tue, Mar 30, 2021 at 1:36 AM Larry McVoy <lm@mcvoy.com <mailto:lm@mcvoy.com>> wrote: > > I had *.clients.your-server.de <http://clients.your-server.de/> crawling mcvoy.com <http://mcvoy.com/> in violation of my > > robots.txt. For whatever reason, the tty settings (or something) > > made vi not work, I dunno what the deal is, stty -tabs didn't help. > > > > So I had to resort to ed to write and debug the little program below. > > It was surprisingly pleasant, it's probably the first time I've used ed > > for anything real in at least a decade. My fingers still know it. > > > > +1 for ed. It's how many decades old and still useful? > > > > > > #!/usr/libexec/bitkeeper/bk tclsh > > > > int > > main(void) > > { > > FILE log = popen("/var/log/apache2/dns.l", "r"); > > string buf, ip; > > string dropped{string}; > > > > fconfigure(log, buffering: "line"); > > while (buf = <log>) { > > unless (buf =~ /([^ ]+\.your-server\.de\.) /) continue; > > ip = $1; > > if (defined(dropped{ip})) continue; > > dropped{ip} = "yes"; > > warn("DROP ${ip}\n"); > > system("/sbin/iptables -I INPUT -s ${ip} -j DROP"); > > } > > } > -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
Technically, the DEC DECwriter series were dot-matrix printers, not line printers. They differed from their Teletype predecessors only in print-head technology, but both printed a single character at a time. Daisywheel printers were similar. Line printers are distinguished not by the width of the paper but by the printer having enough print heads to print an entire line of output at a time. That speed advantage made them the preferred output device for many-page program listings, as opposed to a teleprinter terminals which were more suitable for interactive computing. There were dot-matrix line printers of the late 1970s made by Printronix, which is apparently still around. Erik Fair
Whatever we had, it was slow. Printed one char at a time. So you got good and memorizing the code and only asking to see it rarely. Be funny trying to explain this to my kids. I think they'd get it at some level but really have no idea how much we worked to not let the printer do anything. On Mon, Mar 29, 2021 at 02:10:15PM -0700, Erik E. Fair wrote: > Technically, the DEC DECwriter series were dot-matrix printers, not line printers. They differed from their Teletype predecessors only in print-head technology, but both printed a single character at a time. Daisywheel printers were similar. > > Line printers are distinguished not by the width of the paper but by the printer having enough print heads to print an entire line of output at a time. That speed advantage made them the preferred output device for many-page program listings, as opposed to a teleprinter terminals which were more suitable for interactive computing. > > There were dot-matrix line printers of the late 1970s made by Printronix, which is apparently still around. > > Erik Fair -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
[-- Attachment #1: Type: text/plain, Size: 3669 bytes --] On Mon, Mar 29, 2021 at 5:16 PM Erik E. Fair <fair-tuhs@netbsd.org> wrote: > Technically, the DEC DECwriter series were dot-matrix printers, not line > printers. They differed from their Teletype predecessors only in print-head > technology, but both printed a single character at a time. Daisywheel > printers were similar. > Right.... > Line printers are distinguished not by the width of the paper but by the > printer having enough print heads to print an entire line of output at a > time. That speed advantage made them the preferred output device for > many-page program listings, as opposed to a teleprinter terminals which > were more suitable for interactive computing. > There were originally two styles, the drum printers which DEC sold(e.g. LP20) and the chain printers that IBM offered (e.g. 1401). The drum had all the characters in each of the 132 columns (the upper case only printers were faster because the alphabet was on the drum in two places). The IBM ones has slugs on a rapidly spinning chain that was horizontal (and parallel) to the line being printed. The chain was easily replaceable by the operator - which was one of the duties we would have. When a user queued a printer a set of symbols (*i.e.* the chain of the needed output characters) was specified and the system queued it until the printer had been properly provisioned. For instance, CMU printed checks with a special chain and film ink, so once a night the operator would configure the printer, and tell the queue to print them). Some chains were faster than others, the standard one had N copies of each character. In common to both schemes is that each both styles had 132 hammers and when the proper character was in the position needed, the hammer fired to make an impression the ribbon on the paper, which was caused the noise people associated with computer printers. The high-end IBM 1401 had a hydraulic cover that came down over it and was controlled by the channel processor (it would auto-open when it needed to be serviced - like a new box of paper). But even with the cover down it still loud. The original DEC ones were OEM'ed from Centronix and were noted for always being a little random on the hammer timing and thus the print on the paper often looked like the characters bounced on the line. I remember the ones we had on the PDP-10s were awful and the issue with BLISS is that the dot operator is extremely important to your code and the dots were sometimes notoriously missing. Cabling could be difficult too. They were parallel devices and were supposed to have shorter cables (*i.e.* in the machine room). IBM used its own interface, but by the mid-1970s the Centronix printers were pretty standard on the mini-computers and their parallel interface became the standard (in fact the IBM PC supplied a Centronix parallel interface). > > There were dot-matrix line printers of the late 1970s made by Printronix, > which is apparently still around. > IIRC, in 1979 the Printronix cost about $5K, plus another $300-$500 for an Arduino sized parallel to serial converter that they sold so the printer could be remote on a 9600 baud serial line. Until the cheaper lasers came about, these were often the standard printers that UNIX sites had [I was told once that the original Lion's book was printed on one]. They were about ½ the cost of the DEC printers and since it will all pins, did not have the bounce issue the drums had. When the UNIX boxes started to appear at CMU we used them, and IIRC @ UC Berkeley, we had a number of them around Cory Hall also. ᐧ [-- Attachment #2: Type: text/html, Size: 6835 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1982 bytes --] > > > On Mon, Mar 29, 2021 at 5:16 PM Erik E. Fair <fair-tuhs@netbsd.org> wrote: > > Line printers are distinguished not by the width of the paper but by the >> printer having enough print heads to print an entire line of output at a >> time. That speed advantage made them the preferred output device for >> many-page program listings, as opposed to a teleprinter terminals which >> were more suitable for interactive computing. >> > There were originally two styles, the drum printers which DEC sold(e.g. > LP20) and the chain printers that IBM offered (e.g. 1401). The drum had > all the characters in each of the 132 columns (the upper case only printers > were faster because the alphabet was on the drum in two places). The IBM ones > has slugs on a rapidly spinning chain that was horizontal (and parallel) > to the line being printed. The chain was easily replaceable by the > operator - which was one of the duties we would have. When a user queued a > printer a set of symbols (*i.e.* the chain of the needed output > characters) was specified and the system queued it until the printer had > been properly provisioned. For instance, CMU printed checks with a > special chain and film ink, so once a night the operator would configure > the printer, and tell the queue to print them). Some chains were faster > than others, the standard one had N copies of each character. > > In common to both schemes is that each both styles had 132 hammers and > when the proper character was in the position needed, the hammer fired to > make an impression the ribbon on the paper, which was caused the noise > people associated with computer printers. The high-end IBM 1401 had a > hydraulic cover that came down over it and was controlled by the channel > processor (it would auto-open when it needed to be serviced - like a new > box of paper). > > This led to the "first commandment of fancy printers": Thou shalt not leave thine coffee on top of the printer. -- jpl [-- Attachment #2: Type: text/html, Size: 4081 bytes --]
> the hammer fired to make an impression the ribbon on the paper, which was
> caused the noise people associated with computer printers.
GE outdid the printer with a fantastically fast pneumatic card reader. The make
and break of the suction on each card repeated at aural frequency and so loud
that I hied off to the instrument stockroom to borrow a noise meter. It was 90db
at the operator's position.
[-- Attachment #1: Type: text/plain, Size: 2261 bytes --] On Mon, Mar 29, 2021 at 11:59 AM Norman Wilson <norman@oclsc.org> wrote: > The b command (stands for browse) came from late-1970s > U of T; rob probably brought it to 1127. It's little things like this that make me use ex rather than ed, though it is spelled z there. Linux ed has z as an extension. > There were a > handful of other syntactic conveniences, like being > allowed to leave off the final delimeter of an s command, > and declaring that a missing address means 1 before the > comma or semicolon and $ after, so > 3,s/fish/&head > works over all lines from 3 to the last, and , standing > alone addresses the whole buffer. > Those things are in Posix now. Linux ed is a superset of Posix; *BSD ed is rather lacking, being based on an old SVID. > Also the idea that s followed by a digit N means start > with the Nth instance of the pattern: > s3/fish/&head/ > affects only the third fish, and > s3/fish/&head/g > every fish after the second. > That's neither Posix ed nor ex, and very annoying it is to lack it. > b. The > < | commands, [...] make qed into a kind of workbench, > both for massaging data and for constructing a list > of commands to send to the shell. > > I gather current Linux/BSD eds have > and <, spelled > r ! and w !, but without | it just ain't the same, > rather like the way | revolutionized the shell. > Ex extends the ! command to accept numeric arguments and has the same semantics. Unfortunately, although "r !" and "w !" are in both Posix ed and ex, in ex "w !foo" means "output to the foo command" whereas "w! foo" means "write to foo, ignoring the internal 'don't overwrite' bit that you can set." I wrote two specs that may be of interest to someone: <https://github.com/johnwcowan/exx/blob/master/exx/exx-features.txt> was my attempt to describe "ex extended" that could still be a lightweight editor by not needing the vi bag on the side. <https://github.com/johnwcowan/exx/blob/master/sam/sam-extensions.txt> is a list of things that make me not want to use sam -d editing until they are provided in some form. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org On the Semantic Web, it's too hard to prove you're not a dog. --Bill de hOra [-- Attachment #2: Type: text/html, Size: 6322 bytes --]
I spent a few years working with a CDC 3800, which also had a pneumatic card reader, along with several other noisy peripherals. Although I have no way to prove this, I suspect that my current hearing issues stem from the noise in that machine room.
-r
> On Mar 29, 2021, at 16:21, M Douglas McIlroy <m.douglas.mcilroy@dartmouth.edu> wrote:
>
> GE outdid the printer with a fantastically fast pneumatic card reader. The make and break of the suction on each card repeated at aural frequency and so loud that I hied off to the instrument stockroom to borrow a noise meter. It was 90db at the operator's position.
[-- Attachment #1: Type: text/plain, Size: 2230 bytes --] Night operators were known to nap on top of the 1401s. When there was a need for more paper, they would be gently awakened. -rob On Tue, Mar 30, 2021 at 9:30 AM John P. Linderman <jpl.jpl@gmail.com> wrote: > >> On Mon, Mar 29, 2021 at 5:16 PM Erik E. Fair <fair-tuhs@netbsd.org> >> wrote: >> > > >> Line printers are distinguished not by the width of the paper but by the >>> printer having enough print heads to print an entire line of output at a >>> time. That speed advantage made them the preferred output device for >>> many-page program listings, as opposed to a teleprinter terminals which >>> were more suitable for interactive computing. >>> >> There were originally two styles, the drum printers which DEC sold(e.g. >> LP20) and the chain printers that IBM offered (e.g. 1401). The drum had >> all the characters in each of the 132 columns (the upper case only printers >> were faster because the alphabet was on the drum in two places). The >> IBM ones has slugs on a rapidly spinning chain that was horizontal (and parallel) >> to the line being printed. The chain was easily replaceable by the >> operator - which was one of the duties we would have. When a user queued a >> printer a set of symbols (*i.e.* the chain of the needed output >> characters) was specified and the system queued it until the printer had >> been properly provisioned. For instance, CMU printed checks with a >> special chain and film ink, so once a night the operator would configure >> the printer, and tell the queue to print them). Some chains were faster >> than others, the standard one had N copies of each character. >> >> In common to both schemes is that each both styles had 132 hammers and >> when the proper character was in the position needed, the hammer fired to >> make an impression the ribbon on the paper, which was caused the noise >> people associated with computer printers. The high-end IBM 1401 had a >> hydraulic cover that came down over it and was controlled by the channel >> processor (it would auto-open when it needed to be serviced - like a new >> box of paper). >> >> This led to the "first commandment of fancy printers": Thou shalt not > leave thine coffee on top of the printer. -- jpl > [-- Attachment #2: Type: text/html, Size: 4606 bytes --]
John P. Linderman [30.03.2021 00:29]:
> In common to both schemes is that each both styles had 132 hammers
> and when the proper character was in the position needed, the hammer
> fired to make an impression the ribbon on the paper, which was
> caused the noise people associated with computer printers. The
> high-end IBM 1401 had a hydraulic cover that came down over it and
> was controlled by the channel processor (it would auto-open when it
> needed to be serviced - like a new box of paper).
>
> This led to the "first commandment of fancy printers": Thou shalt not
> leave thine coffee on top of the printer. -- jpl
A former co-worker told me he had once placed a deck of punched cards on
top of such a printer...he didn't do it a second time.
--
Hilsen Harald
Andy Kosela <akosela@andykosela.com> wrote:
> On 3/29/21, arnold@skeeve.com <arnold@skeeve.com> wrote:
> > Andy Kosela <akosela@andykosela.com> wrote:
> >
> >> If ed(1) had cursor positioning and full screen capabilities along
> >> with line oriented editing (similar to Atari 8-bit default editor) it
> >> would be perfect. I still love it though and use it pretty often.
> >
> > Try out the 'se' editor, see www.se-editor.org.
>
> Thanks. It is a nice editor, but it actually resembles ex(1) when
> using visual mode. Maybe I am missing something but it appears you
> cannot actually use cursor keys to visually edit lines in the upper
> area of the screen in se -- you can only edit cmd line.
>
> As far as I know there is no editor in the Unix land which gives you
> the ability to work in the ed(1) line oriented mode BUT also allowing
> to freely move cursor keys in all directions. I gave example of the
> Atari editor[1] which does exactly that. I believe to accomplish it
> on Unix one would need to hack ed(1) and add ncurses(3) cursor
> positioning.
>
> --Andy
>
> [1] https://youtu.be/c9o92l5gupI
[-- Attachment #1: Type: text/plain, Size: 1668 bytes --] As I recall, the Dataproducts band printers BP1000, BP2000 only had a single hammer per column. But the band containing the full character set moved so quickly into position for each column that the print speed was incredible. We had both models at one point and the 2000 was an absolute screamer. Paper just flew over the paper guides to the collection basket in the rear. It was impressive and incredible to watch in action. The bands were easily replaceable via a release lever. So you could change fonts, replace damaged bands, etc. Sharp as heck as I recall on the edges. You also had to make sure it lined up just right before engaging the tension lever. With cover down, they were remarkably quiet in comparison to other "high speed" printers I had been around. Real good at multipart forms at making clean clear impressions on the backmost layer. On Mon, Mar 29, 2021, 5:16 PM Erik E. Fair <fair-tuhs@netbsd.org> wrote: > Technically, the DEC DECwriter series were dot-matrix printers, not line > printers. They differed from their Teletype predecessors only in print-head > technology, but both printed a single character at a time. Daisywheel > printers were similar. > > Line printers are distinguished not by the width of the paper but by the > printer having enough print heads to print an entire line of output at a > time. That speed advantage made them the preferred output device for > many-page program listings, as opposed to a teleprinter terminals which > were more suitable for interactive computing. > > There were dot-matrix line printers of the late 1970s made by Printronix, > which is apparently still around. > > Erik Fair > [-- Attachment #2: Type: text/html, Size: 2161 bytes --]
[-- Attachment #1: Type: text/plain, Size: 164 bytes --] I missed the fact that Posix and Linux ed support s/foo/bar/3 (as opposed to s3/foo/bar); ex does not, unfortunately. We need a Great Unification of Line Editors. [-- Attachment #2: Type: text/html, Size: 497 bytes --]
John Cowan: We need a Great Unification of Line Editors. ==== A standard for the standard editor? I thought the nice thing about standards was that there were so many of them. Norman Wilson Toronto ON
[-- Attachment #1: Type: text/plain, Size: 1458 bytes --] On Tue, Mar 30, 2021 at 9:03 PM Norman Wilson <norman@oclsc.org> wrote: A standard for the standard editor? > No, I mean an implementation that provides the union of features (and preferably though not necessarily of syntaxes) in Posix ed and ex, GNU ed, the ex mode of vim, and BSD ed. I thought the nice thing about standards was that there > were so many of them. > ... and if you don't like any of them, wait till next year, yes. But (to use examples of local significance) who would have foreseen that a character encoding standard put forward in 1992 for an obscure OS in 1992 would so completely take over the world, or for that matter another obscure OS written by the same people in 1969? It's fine to complain that there is no more research in such-and-such an area; however, while many projects are worked on forever and the great majority are abandoned, there is a third kind of project that is simply *finished*. Cal, for example, provides the same output in both Linux and BSD versions as the Seventh Edition when given the original arguments (except for titlecasing the weekday names), though both have additional bells and whistles such as being able to set the date of the Gregorian reform. John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org Gules six bars argent on a canton azure 50 mullets argent six five six five six five six five and six --blazoning the U.S. flag <http://web.meson.org/blazonserver> [-- Attachment #2: Type: text/html, Size: 3345 bytes --]
On Mar 30, 2021, at 4:38 PM, John Cowan <cowan@ccil.org> wrote: > > I missed the fact that Posix and Linux ed support s/foo/bar/3 (as opposed to s3/foo/bar); ex does not, unfortunately. By analogy with s/RE/replacement/g, it would have made more sense to allow sN/foo/bar/M to mean replace M instances of foo with bar, starting the Nth instance of foo. N & M default to 1. M can also be g. > We need a Great Unification of Line Editors. Add in sam's command language as well! Alternately I'd want k style array language built in, enhanced with regexps.