* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
@ 2022-12-11 0:42 Nelson H. F. Beebe
2022-12-11 2:16 ` Larry McVoy
0 siblings, 1 reply; 25+ messages in thread
From: Nelson H. F. Beebe @ 2022-12-11 0:42 UTC (permalink / raw)
To: tuhs
Clem Cole mentions kermit in connection with the question raised about
the uses of the cu utility.
As an FYI, Kermit's author, Frank da Cruz, is preparing a final
release, version 10.0, and I've been working with him on testing
builds in numerous environments. There are frequent updates during
this work, and the latest snapshots can be found at
https://kermitproject.org/ftp/kermit/pretest/
The x-YYYYMMDD.* bundles do not contain a leading directory, so be
careful to unpack them in an empty directory. The build relies on a
lengthy makefile with platform-specific target names, like irix65,
linux, and solaris11: the leading comments in the makefile provide
further guidance.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 0:42 [TUHS] Re: Stdin Redirect in Cu History/Alternatives? Nelson H. F. Beebe
@ 2022-12-11 2:16 ` Larry McVoy
2022-12-11 2:26 ` Warner Losh
0 siblings, 1 reply; 25+ messages in thread
From: Larry McVoy @ 2022-12-11 2:16 UTC (permalink / raw)
To: Nelson H. F. Beebe; +Cc: tuhs
Wow, Kermit is still around? I think the last time I used that was
around 1985.
Are modems still a thing?
On Sat, Dec 10, 2022 at 05:42:14PM -0700, Nelson H. F. Beebe wrote:
> Clem Cole mentions kermit in connection with the question raised about
> the uses of the cu utility.
>
> As an FYI, Kermit's author, Frank da Cruz, is preparing a final
> release, version 10.0, and I've been working with him on testing
> builds in numerous environments. There are frequent updates during
> this work, and the latest snapshots can be found at
>
> https://kermitproject.org/ftp/kermit/pretest/
>
> The x-YYYYMMDD.* bundles do not contain a leading directory, so be
> careful to unpack them in an empty directory. The build relies on a
> lengthy makefile with platform-specific target names, like irix65,
> linux, and solaris11: the leading comments in the makefile provide
> further guidance.
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe Tel: +1 801 581 5254 -
> - University of Utah -
> - Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
> - 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
> - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
> -------------------------------------------------------------------------------
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 2:16 ` Larry McVoy
@ 2022-12-11 2:26 ` Warner Losh
2022-12-11 2:32 ` Larry McVoy
0 siblings, 1 reply; 25+ messages in thread
From: Warner Losh @ 2022-12-11 2:26 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]
On Sat, Dec 10, 2022, 7:16 PM Larry McVoy <lm@mcvoy.com> wrote:
> Wow, Kermit is still around? I think the last time I used that was
> around 1985.
>
> Are modems still a thing?
>
I used it last year... without a modem.
Warner
> On Sat, Dec 10, 2022 at 05:42:14PM -0700, Nelson H. F. Beebe wrote:
> > Clem Cole mentions kermit in connection with the question raised about
> > the uses of the cu utility.
> >
> > As an FYI, Kermit's author, Frank da Cruz, is preparing a final
> > release, version 10.0, and I've been working with him on testing
> > builds in numerous environments. There are frequent updates during
> > this work, and the latest snapshots can be found at
> >
> > https://kermitproject.org/ftp/kermit/pretest/
> >
> > The x-YYYYMMDD.* bundles do not contain a leading directory, so be
> > careful to unpack them in an empty directory. The build relies on a
> > lengthy makefile with platform-specific target names, like irix65,
> > linux, and solaris11: the leading comments in the makefile provide
> > further guidance.
> >
> >
> -------------------------------------------------------------------------------
> > - Nelson H. F. Beebe Tel: +1 801 581 5254
> -
> > - University of Utah
> -
> > - Department of Mathematics, 110 LCB Internet e-mail:
> beebe@math.utah.edu -
> > - 155 S 1400 E RM 233 beebe@acm.org
> beebe@computer.org -
> > - Salt Lake City, UT 84112-0090, USA URL:
> http://www.math.utah.edu/~beebe/ -
> >
> -------------------------------------------------------------------------------
>
> --
> ---
> Larry McVoy Retired to fishing
> http://www.mcvoy.com/lm/boat
>
[-- Attachment #2: Type: text/html, Size: 3058 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 2:26 ` Warner Losh
@ 2022-12-11 2:32 ` Larry McVoy
2022-12-11 2:33 ` Warner Losh
0 siblings, 1 reply; 25+ messages in thread
From: Larry McVoy @ 2022-12-11 2:32 UTC (permalink / raw)
To: Warner Losh; +Cc: The Eunuchs Hysterical Society
On Sat, Dec 10, 2022 at 07:26:09PM -0700, Warner Losh wrote:
> On Sat, Dec 10, 2022, 7:16 PM Larry McVoy <lm@mcvoy.com> wrote:
>
> > Wow, Kermit is still around? I think the last time I used that was
> > around 1985.
> >
> > Are modems still a thing?
>
> I used it last year... without a modem.
What problem does it solve that is not solved?
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 2:32 ` Larry McVoy
@ 2022-12-11 2:33 ` Warner Losh
2022-12-11 2:39 ` Larry McVoy
0 siblings, 1 reply; 25+ messages in thread
From: Warner Losh @ 2022-12-11 2:33 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 666 bytes --]
On Sat, Dec 10, 2022 at 7:32 PM Larry McVoy <lm@mcvoy.com> wrote:
> On Sat, Dec 10, 2022 at 07:26:09PM -0700, Warner Losh wrote:
> > On Sat, Dec 10, 2022, 7:16 PM Larry McVoy <lm@mcvoy.com> wrote:
> >
> > > Wow, Kermit is still around? I think the last time I used that was
> > > around 1985.
> > >
> > > Are modems still a thing?
> >
> > I used it last year... without a modem.
>
> What problem does it solve that is not solved?
>
Talking to my DEC Rainbow and downloading files to it? It was the go-to
protocol of choice. Xmodem is available, but messes up file sizes. kermit
just works with this device that's so slow it drops characters at 2400 baud.
Warner
[-- Attachment #2: Type: text/html, Size: 1144 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 2:33 ` Warner Losh
@ 2022-12-11 2:39 ` Larry McVoy
2022-12-11 2:49 ` Bakul Shah
` (3 more replies)
0 siblings, 4 replies; 25+ messages in thread
From: Larry McVoy @ 2022-12-11 2:39 UTC (permalink / raw)
To: Warner Losh; +Cc: The Eunuchs Hysterical Society
On Sat, Dec 10, 2022 at 07:33:54PM -0700, Warner Losh wrote:
> On Sat, Dec 10, 2022 at 7:32 PM Larry McVoy <lm@mcvoy.com> wrote:
>
> > On Sat, Dec 10, 2022 at 07:26:09PM -0700, Warner Losh wrote:
> > > On Sat, Dec 10, 2022, 7:16 PM Larry McVoy <lm@mcvoy.com> wrote:
> > >
> > > > Wow, Kermit is still around? I think the last time I used that was
> > > > around 1985.
> > > >
> > > > Are modems still a thing?
> > >
> > > I used it last year... without a modem.
> >
> > What problem does it solve that is not solved?
>
> Talking to my DEC Rainbow and downloading files to it? It was the go-to
> protocol of choice. Xmodem is available, but messes up file sizes. kermit
> just works with this device that's so slow it drops characters at 2400 baud.
OK, that is cool, but my question was what problem does it solve that
we face today? Other than talking to 30-40 year old hardware. Why is
Kermit still a thing?
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 2:39 ` Larry McVoy
@ 2022-12-11 2:49 ` Bakul Shah
2022-12-11 3:10 ` Phil Budne
` (2 subsequent siblings)
3 siblings, 0 replies; 25+ messages in thread
From: Bakul Shah @ 2022-12-11 2:49 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Eunuchs Hysterical Society
> On Dec 10, 2022, at 6:39 PM, Larry McVoy <lm@mcvoy.com> wrote:
>
> On Sat, Dec 10, 2022 at 07:33:54PM -0700, Warner Losh wrote:
>> On Sat, Dec 10, 2022 at 7:32 PM Larry McVoy <lm@mcvoy.com> wrote:
>>
>>> On Sat, Dec 10, 2022 at 07:26:09PM -0700, Warner Losh wrote:
>>>> On Sat, Dec 10, 2022, 7:16 PM Larry McVoy <lm@mcvoy.com> wrote:
>>>>
>>>>> Wow, Kermit is still around? I think the last time I used that was
>>>>> around 1985.
>>>>>
>>>>> Are modems still a thing?
>>>>
>>>> I used it last year... without a modem.
>>>
>>> What problem does it solve that is not solved?
>>
>> Talking to my DEC Rainbow and downloading files to it? It was the go-to
>> protocol of choice. Xmodem is available, but messes up file sizes. kermit
>> just works with this device that's so slow it drops characters at 2400 baud.
>
> OK, that is cool, but my question was what problem does it solve that
> we face today? Other than talking to 30-40 year old hardware. Why is
> Kermit still a thing?
I used it to connect to various RaspberryPis. Also to check what a
GPS dongle was outputting. My ~/.kermrc has a date of Oct 2019. Later
switched to minicom/picocom. Don't recall why. Kermit has a decent
help system.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 2:39 ` Larry McVoy
2022-12-11 2:49 ` Bakul Shah
@ 2022-12-11 3:10 ` Phil Budne
2022-12-11 4:17 ` Dan Cross
2022-12-12 17:06 ` Doug McIntyre
3 siblings, 0 replies; 25+ messages in thread
From: Phil Budne @ 2022-12-11 3:10 UTC (permalink / raw)
To: tuhs
Larry McVoy asked:
> Why is Kermit still a thing?>
I've used it in recent-ish history to transfer files to ancient
operating systems running under SimH. SimH will provide what looks
like a serial mux to the ancient software and speaks TCP to the modern
world.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 2:39 ` Larry McVoy
2022-12-11 2:49 ` Bakul Shah
2022-12-11 3:10 ` Phil Budne
@ 2022-12-11 4:17 ` Dan Cross
2022-12-11 4:45 ` Will Senn
2022-12-12 17:06 ` Doug McIntyre
3 siblings, 1 reply; 25+ messages in thread
From: Dan Cross @ 2022-12-11 4:17 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]
On Sat, Dec 10, 2022, 9:40 PM Larry McVoy <lm@mcvoy.com> wrote:
> On Sat, Dec 10, 2022 at 07:33:54PM -0700, Warner Losh wrote:
> > On Sat, Dec 10, 2022 at 7:32 PM Larry McVoy <lm@mcvoy.com> wrote:
> >
> > > On Sat, Dec 10, 2022 at 07:26:09PM -0700, Warner Losh wrote:
> > > > On Sat, Dec 10, 2022, 7:16 PM Larry McVoy <lm@mcvoy.com> wrote:
> > > >
> > > > > Wow, Kermit is still around? I think the last time I used that was
> > > > > around 1985.
> > > > >
> > > > > Are modems still a thing?
> > > >
> > > > I used it last year... without a modem.
> > >
> > > What problem does it solve that is not solved?
> >
> > Talking to my DEC Rainbow and downloading files to it? It was the go-to
> > protocol of choice. Xmodem is available, but messes up file sizes. kermit
> > just works with this device that's so slow it drops characters at 2400
> baud.
>
> OK, that is cool, but my question was what problem does it solve that
> we face today? Other than talking to 30-40 year old hardware. Why is
> Kermit still a thing?
>
Aside from talking to legacy systems, the Kermit protocol probably has
little to recommend it (xmodem specifically still gets a bit of a workout
in embedded/firmware spaces because it's dead simple). Kermit as a
communications swiss army knife of a program is probably more useful.
That said, I could see it for downloading bulk data from scada systems over
a slow link (RF, serial, or maybe some weird 7 bit thing). I tend to doubt
that's happening much with Kermit these days, though.
- Dan C.
[-- Attachment #2: Type: text/html, Size: 2477 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 4:17 ` Dan Cross
@ 2022-12-11 4:45 ` Will Senn
0 siblings, 0 replies; 25+ messages in thread
From: Will Senn @ 2022-12-11 4:45 UTC (permalink / raw)
To: tuhs
[-- Attachment #1: Type: text/plain, Size: 2055 bytes --]
On 12/10/22 10:17 PM, Dan Cross wrote:
> On Sat, Dec 10, 2022, 9:40 PM Larry McVoy <lm@mcvoy.com> wrote:
>
> On Sat, Dec 10, 2022 at 07:33:54PM -0700, Warner Losh wrote:
> > On Sat, Dec 10, 2022 at 7:32 PM Larry McVoy <lm@mcvoy.com> wrote:
> >
> > > On Sat, Dec 10, 2022 at 07:26:09PM -0700, Warner Losh wrote:
> > > > On Sat, Dec 10, 2022, 7:16 PM Larry McVoy <lm@mcvoy.com> wrote:
> > > >
> > > > > Wow, Kermit is still around? I think the last time I used
> that was
> > > > > around 1985.
> > > > >
> > > > > Are modems still a thing?
> > > >
> > > > I used it last year... without a modem.
> > >
> > > What problem does it solve that is not solved?
> >
> > Talking to my DEC Rainbow and downloading files to it? It was
> the go-to
> > protocol of choice. Xmodem is available, but messes up file
> sizes. kermit
> > just works with this device that's so slow it drops characters
> at 2400 baud.
>
> OK, that is cool, but my question was what problem does it solve that
> we face today? Other than talking to 30-40 year old hardware. Why is
> Kermit still a thing?
>
>
> Aside from talking to legacy systems, the Kermit protocol probably has
> little to recommend it (xmodem specifically still gets a bit of a
> workout in embedded/firmware spaces because it's dead simple). Kermit
> as a communications swiss army knife of a program is probably more useful.
>
> That said, I could see it for downloading bulk data from scada systems
> over a slow link (RF, serial, or maybe some weird 7 bit thing). I tend
> to doubt that's happening much with Kermit these days, though.
It works, it's not flaky and it will talk to practically anything. I use
it for talking with virtual systems running older OSes (Mac, unix, etc)
where other stuff doesn't or just sorta works, if you can run kermit and
theres a path, it'll prolly work more often than not, and certainly more
than more exotic stuff.
[-- Attachment #2: Type: text/html, Size: 4036 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 2:39 ` Larry McVoy
` (2 preceding siblings ...)
2022-12-11 4:17 ` Dan Cross
@ 2022-12-12 17:06 ` Doug McIntyre
3 siblings, 0 replies; 25+ messages in thread
From: Doug McIntyre @ 2022-12-12 17:06 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
On Sat, Dec 10, 2022 at 06:39:55PM -0800, Larry McVoy wrote:
> OK, that is cool, but my question was what problem does it solve that
> we face today? Other than talking to 30-40 year old hardware. Why is
> Kermit still a thing?
Up until recent, I used kermit on my mac laptop to talk out multiple serial ports
to control different devices configured over serial quite regularly.
(Now I use the Serial.app)
There were other ways to do it, but kermit was familure, and worked flawlessy.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 15:04 ` Dan Cross
@ 2022-12-13 1:54 ` Larry McVoy
0 siblings, 0 replies; 25+ messages in thread
From: Larry McVoy @ 2022-12-13 1:54 UTC (permalink / raw)
To: Dan Cross; +Cc: Michael Kj??rling, tuhs
On Sun, Dec 11, 2022 at 10:04:54AM -0500, Dan Cross wrote:
> I think this is in line with Larry's question about non-legacy
> use-cases for these ancient serial transfer protocols in late 2022.
Indeed, this was just what I was looking for. I had no idea that
serial transfer protocols were still useful.
It makes me wish I had kept the source for quicknet, I wrote my
own file transfer and remote terminal for CP/M in the middle
1980s. I did it just because I wanted things to work a certain
way and none of the other options did what I wanted. quicknet was
really pleasant on a 128K Z80 (not really 128K because the screen
was mapped in there, but more than 64K). I spent many a pleasant
hour logged in to uwvax in quicknet, got a lot of work done.
Thanks to you and others who had shown that serial transfer still
matters. Who knew? You did.
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-12 21:34 ` Dave Horsfall
@ 2022-12-12 21:46 ` Chet Ramey
0 siblings, 0 replies; 25+ messages in thread
From: Chet Ramey @ 2022-12-12 21:46 UTC (permalink / raw)
To: Dave Horsfall, The Eunuchs Hysterical Society
On 12/12/22 4:34 PM, Dave Horsfall wrote:
>> My main job, for the 20 years until I retired, was to keep telling
>> people that code that you wrote 6 months ago might as well have been
>> written by someone else. Optimize for reading the code, not writing the
>> code. It's read many.
>
> I should clarify that on the odd occasion that I write obscure code it's
> for efficiency, and I comment it well because *I* might be the one to
> maintain it six months hence :-)
Six months? Try ten years. :-)
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 20:03 ` Larry McVoy
2022-12-11 23:22 ` segaloco via TUHS
@ 2022-12-12 21:34 ` Dave Horsfall
2022-12-12 21:46 ` Chet Ramey
1 sibling, 1 reply; 25+ messages in thread
From: Dave Horsfall @ 2022-12-12 21:34 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
On Sun, 11 Dec 2022, Larry McVoy wrote:
> > I've always used the maxim "Write code as though the next person to
> > maintain it is an axe-wielding psychopath who knows where you live".
>
> My main job, for the 20 years until I retired, was to keep telling
> people that code that you wrote 6 months ago might as well have been
> written by someone else. Optimize for reading the code, not writing the
> code. It's read many.
I should clarify that on the odd occasion that I write obscure code it's
for efficiency, and I comment it well because *I* might be the one to
maintain it six months hence :-)
-- Dave
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
@ 2022-12-12 17:42 Nelson H. F. Beebe
0 siblings, 0 replies; 25+ messages in thread
From: Nelson H. F. Beebe @ 2022-12-12 17:42 UTC (permalink / raw)
To: tuhs
After my posting on Sat, 10 Dec 2022 17:42:14 -0700 about the recent
work on kermit 10.0, some readers asked why a serial line connection
and file transfer tool was still of interest, and a few others
responded with use cases.
Modern kermit has for several years supported ssh connections, and
Unicode, as well: here is a top-level command list:
% kermit
(~/) C-Kermit>? Command, one of the following:
add define hangup msleep resend telnet
answer delete HELP open return touch
apc dial if orientation rlogin trace
array directory increment output rmdir translate
ask disable input pause run transmit
askq do INTRO pdial screen type
assign echo kcd pipe script undeclare
associate edit learn print send undefine
back enable LICENSE pty server version
browse end lineout purge set void
bye evaluate log push shift wait
cd exit login pwd show where
change file logout quit space while
check finish lookup read ssh who
chmod for mail receive statistics write
clear ftp manual redial status xecho
close get message redirect stop xmessage
connect getc minput redo SUPPORT
convert getok mget reget suspend
copy goto mkdir remote switch
date grep mmove remove tail
decrement head msend rename take
or one of the tokens: ! # ( . ; : < @ ^ {
Here are the descriptions of connection and character set translations:
(~/) C-Kermit>help ssh
Syntax: SSH [ options ] <hostname> [ command ]
Makes an SSH connection using the external ssh program via the SET SSH
COMMAND string, which is "ssh -e none" by default. Options for the
external ssh program may be included. If the hostname is followed by a
command, the command is executed on the host instead of an interactive
shell.
(~/) C-Kermit>help connect
Syntax: CONNECT (or C, or CQ) [ switches ]
Connect to a remote computer via the serial communications device given in
the most recent SET LINE command, or to the network host named in the most
recent SET HOST command. Type the escape character followed by C to get
back to the C-Kermit prompt, or followed by ? for a list of CONNECT-mode
escape commands.
Include the /QUIETLY switch to suppress the informational message that
tells you how to escape back, etc. CQ is a synonym for CONNECT /QUIETLY.
Other switches include:
/TRIGGER:string
One or more strings to look for that will cause automatic return to
command mode. To specify one string, just put it right after the
colon, e.g. "/TRIGGER:Goodbye". If the string contains any spaces, you
must enclose it in braces, e.g. "/TRIGGER:{READY TO SEND...}". To
specify more than one trigger, use the following format:
/TRIGGER:{{string1}{string2}...{stringn}}
Upon return from CONNECT mode, the variable \v(trigger) is set to the
trigger string, if any, that was actually encountered. This value, like
all other CONNECT switches applies only to the CONNECT command with which
it is given, and overrides (temporarily) any global SET TERMINAL TRIGGER
string that might be in effect.
Your escape character is Ctrl-\ (ASCII 28, FS)
(~/) C-Kermit>help translate
Syntax: CONVERT file1 cs1 cs2 [ file2 ]
Synonym: TRANSLATE
Converts file1 from the character set cs1 into the character set cs2
and stores the result in file2. The character sets can be any of
C-Kermit's file character sets. If file2 is omitted, the translation
is displayed on the screen. An appropriate intermediate character-set
is chosen automatically, if necessary. Synonym: XLATE. Example:
CONVERT lasagna.txt latin1 utf8 lasagna-utf8.txt
Multiple files can be translated if file2 is a directory or device name,
rather than a filename, or if file2 is omitted.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah -
- Department of Mathematics, 110 LCB Internet e-mail: beebe@math.utah.edu -
- 155 S 1400 E RM 233 beebe@acm.org beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 20:03 ` Larry McVoy
@ 2022-12-11 23:22 ` segaloco via TUHS
2022-12-12 21:34 ` Dave Horsfall
1 sibling, 0 replies; 25+ messages in thread
From: segaloco via TUHS @ 2022-12-11 23:22 UTC (permalink / raw)
To: Larry McVoy; +Cc: The Eunuchs Hysterical Society
Readable code also contributes to easier documentation. It's easier to maintain a manual when you can just translate the code into the local language. My current team started small and I learned pretty soon that time invested in a habit of readable code meant less time spent providing the person assigned documentation the juicy details.
- Matt G.
------- Original Message -------
On Sunday, December 11th, 2022 at 12:03 PM, Larry McVoy <lm@mcvoy.com> wrote:
> On Mon, Dec 12, 2022 at 06:55:31AM +1100, Dave Horsfall wrote:
>
> > On Sun, 11 Dec 2022, Michael Kj??rling wrote:
> >
> > > By definition, if you write code as cleverly as you can, then you aren't
> > > clever enough to debug it...
> >
> > Indeed...
> >
> > I've always used the maxim "Write code as though the next person to
> > maintain it is an axe-wielding psychopath who knows where you live".
>
>
> My main job, for the 20 years until I retired, was to keep telling
> people that code that you wrote 6 months ago might as well have been
> written by someone else. Optimize for reading the code, not writing
> the code. It's read many.
>
> 99.9% of the time, I detest clever code. .1% of the time, I need it.
> The problem is that smart engineers adore writing clever code. They
> usually, eventually, wise up.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 19:55 ` Dave Horsfall
@ 2022-12-11 20:03 ` Larry McVoy
2022-12-11 23:22 ` segaloco via TUHS
2022-12-12 21:34 ` Dave Horsfall
0 siblings, 2 replies; 25+ messages in thread
From: Larry McVoy @ 2022-12-11 20:03 UTC (permalink / raw)
To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society
On Mon, Dec 12, 2022 at 06:55:31AM +1100, Dave Horsfall wrote:
> On Sun, 11 Dec 2022, Michael Kj??rling wrote:
>
> > By definition, if you write code as cleverly as you can, then you aren't
> > clever enough to debug it...
>
> Indeed...
>
> I've always used the maxim "Write code as though the next person to
> maintain it is an axe-wielding psychopath who knows where you live".
My main job, for the 20 years until I retired, was to keep telling
people that code that you wrote 6 months ago might as well have been
written by someone else. Optimize for reading the code, not writing
the code. It's read many.
99.9% of the time, I detest clever code. .1% of the time, I need it.
The problem is that smart engineers adore writing clever code. They
usually, eventually, wise up.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 18:54 ` Michael Kjörling
@ 2022-12-11 19:55 ` Dave Horsfall
2022-12-11 20:03 ` Larry McVoy
0 siblings, 1 reply; 25+ messages in thread
From: Dave Horsfall @ 2022-12-11 19:55 UTC (permalink / raw)
To: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 322 bytes --]
On Sun, 11 Dec 2022, Michael Kjörling wrote:
> By definition, if you write code as cleverly as you can, then you aren't
> clever enough to debug it...
Indeed...
I've always used the maxim "Write code as though the next person to
maintain it is an axe-wielding psychopath who knows where you live".
-- Dave
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 17:18 ` Adam Thornton
@ 2022-12-11 18:54 ` Michael Kjörling
2022-12-11 19:55 ` Dave Horsfall
0 siblings, 1 reply; 25+ messages in thread
From: Michael Kjörling @ 2022-12-11 18:54 UTC (permalink / raw)
To: tuhs
On 11 Dec 2022 10:18 -0700, from athornton@gmail.com (Adam Thornton):
> The funny thing about that...the project spanned the July 4th
> weekend. I didn't get it working before the 4th. Then when I went in
> very hungover after the weekend, I couldn't figure out quite what I
> had been trying to do, because it was something that was attempting
> to be very clever. So in my dulled state, I rewrote the bottom
> layers to be much more straightforward. Worked the first time. That
> taught me the virtue of not overthinking it.
By definition, if you write code as cleverly as you can, then you
aren't clever enough to debug it...
There's something to be said for simplicity unless for some reason you
really need to be clever. Let's save the clever for the, say, 1% where
it's actually needed; premature application of cleverness is the root
of much evil.
--
✍ Michael Kjörling 🏡 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 13:59 ` Michael Kjörling
2022-12-11 14:28 ` Steve Nickolas
@ 2022-12-11 17:18 ` Adam Thornton
2022-12-11 18:54 ` Michael Kjörling
1 sibling, 1 reply; 25+ messages in thread
From: Adam Thornton @ 2022-12-11 17:18 UTC (permalink / raw)
To: TUHS main list
In the late 1990s I did a brief consulting project to move files between sites. Something to do with customer billing and record transmission, from some large system that was not Internet-connected. It ended up being a terrible teetering tower of kermit, sz or sx, and expect. But it got the job done!
The funny thing about that...the project spanned the July 4th weekend. I didn't get it working before the 4th. Then when I went in very hungover after the weekend, I couldn't figure out quite what I had been trying to do, because it was something that was attempting to be very clever. So in my dulled state, I rewrote the bottom layers to be much more straightforward. Worked the first time. That taught me the virtue of not overthinking it.
Adam
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 14:28 ` Steve Nickolas
@ 2022-12-11 15:04 ` Dan Cross
2022-12-13 1:54 ` Larry McVoy
0 siblings, 1 reply; 25+ messages in thread
From: Dan Cross @ 2022-12-11 15:04 UTC (permalink / raw)
To: Steve Nickolas; +Cc: Michael Kjörling, tuhs
On Sun, Dec 11, 2022 at 9:28 AM Steve Nickolas <usotsuki@buric.co> wrote:
> On Sun, 11 Dec 2022, Michael Kjörling wrote:
> > On 10 Dec 2022 19:22 -0500, from clemc@ccc.com (Clem Cole):
> >> My memory is there were also a bunch of two
> >> letter programs, rx/sx and rz/sz and the like. Frankly its been so long
> >> since I had any use for them, I've forgotten.
> >
> > I remember at least sz/rz from my early (for me) forays into UNIX,
> > back when ZModem was pretty much state of the art at least on micros
> > and I had files locally that I wanted remotely or vice versa. The
> > mnenomic being s(end)/r(eceive) z(modem); "send" and "receive", of
> > course, being local to the remote host, so the opposite sense of what
> > one would do with the terminal emulator program that one interacted
> > with locally. So "sz <some file>" at the prompt, then activate the
> > "receive ZModem transfer" function locally; or "rz <some file>", then
> > activate the "send using ZModem" function locally.
> >
> > I think the host I was on at the time (which appears to have been some
> > Solaris) also offered XModem and YModem variants as [rs][xy], but I
> > never used those because someone had at some point told me that ZModem
> > was better. :-)
>
> Kind-of a pain to type as I'm SSHing in from my phone, but they still
> exist and I have "lrzsz" installed on my Debian box.
And as I mentioned earlier, they're still very much used.
I recently wrote the initial bootstrap program that runs when the x86
cores on our machine come out of reset
(https://github.com/oxidecomputer/phbl/). However, that's for
production use; for internal engineering use we have _another_ tool,
also written in Rust, that is an interactive standalone program. This
lets us do things like poke at physical memory, read/write MSRs, and
all of that fun stuff, before loading an operating system. So how does
one load the OS? Our machine has a part that includes a 3
MBAUD-capable UART, and we use xmodem to transfer the kernel (and a
ramdisk image!) over that, where the engineering tool can load and
jump into it. The standalone program implements xmodem internally,
whereas we use `sx` on the dev host side. Basically, there is a
built-in commands to perform the transfer, another that effectively
says "there's an ELF image in physical memory $here: load it and
return the entry point" and finally another command that can jump to
an arbitrary virtual address (yes, we load the host OS in 64-bit mode
and treat the kernel like any old "normal" ELF binary).
As the ramdisk image has grown (more and more debugging tools are
included as we move ever forward in the bringup and development
process), latency here is annoying. I added support for compressed
kernel and ramdisk images, which gave a 2.5x speedup (directly
proportional to the usual compression ratio we see on these images)
which ameliorated but did not eliminate the pain. We briefly tossed
around the idea of implementing zmodem, but decided it wasn't worth
it. We _could_, in theory, make use of the enhanced kermit with
sliding windows and so on, but again decided it wasn't worth the
effort for an engineering tool.
Incidentally, my colleague Matt Keeter ran into performance and
reliability issues with xmodem over the USB serial driver in macOS,
and wrote a small shim that side-stepped the host OS device. He did a
nice write-up of it here:
https://www.mattkeeter.com/blog/2022-05-31-xmodem/
I think this is in line with Larry's question about non-legacy
use-cases for these ancient serial transfer protocols in late 2022.
- Dan C.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 13:59 ` Michael Kjörling
@ 2022-12-11 14:28 ` Steve Nickolas
2022-12-11 15:04 ` Dan Cross
2022-12-11 17:18 ` Adam Thornton
1 sibling, 1 reply; 25+ messages in thread
From: Steve Nickolas @ 2022-12-11 14:28 UTC (permalink / raw)
To: Michael Kjörling; +Cc: tuhs
[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]
On Sun, 11 Dec 2022, Michael Kjörling wrote:
> On 10 Dec 2022 19:22 -0500, from clemc@ccc.com (Clem Cole):
>> My memory is there were also a bunch of two
>> letter programs, rx/sx and rz/sz and the like. Frankly its been so long
>> since I had any use for them, I've forgotten.
>
> I remember at least sz/rz from my early (for me) forays into UNIX,
> back when ZModem was pretty much state of the art at least on micros
> and I had files locally that I wanted remotely or vice versa. The
> mnenomic being s(end)/r(eceive) z(modem); "send" and "receive", of
> course, being local to the remote host, so the opposite sense of what
> one would do with the terminal emulator program that one interacted
> with locally. So "sz <some file>" at the prompt, then activate the
> "receive ZModem transfer" function locally; or "rz <some file>", then
> activate the "send using ZModem" function locally.
>
> I think the host I was on at the time (which appears to have been some
> Solaris) also offered XModem and YModem variants as [rs][xy], but I
> never used those because someone had at some point told me that ZModem
> was better. :-)
Kind-of a pain to type as I'm SSHing in from my phone, but they still
exist and I have "lrzsz" installed on my Debian box.
-uso.
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 0:22 ` [TUHS] " Clem Cole
2022-12-11 2:37 ` segaloco via TUHS
@ 2022-12-11 13:59 ` Michael Kjörling
2022-12-11 14:28 ` Steve Nickolas
2022-12-11 17:18 ` Adam Thornton
1 sibling, 2 replies; 25+ messages in thread
From: Michael Kjörling @ 2022-12-11 13:59 UTC (permalink / raw)
To: tuhs
On 10 Dec 2022 19:22 -0500, from clemc@ccc.com (Clem Cole):
> My memory is there were also a bunch of two
> letter programs, rx/sx and rz/sz and the like. Frankly its been so long
> since I had any use for them, I've forgotten.
I remember at least sz/rz from my early (for me) forays into UNIX,
back when ZModem was pretty much state of the art at least on micros
and I had files locally that I wanted remotely or vice versa. The
mnenomic being s(end)/r(eceive) z(modem); "send" and "receive", of
course, being local to the remote host, so the opposite sense of what
one would do with the terminal emulator program that one interacted
with locally. So "sz <some file>" at the prompt, then activate the
"receive ZModem transfer" function locally; or "rz <some file>", then
activate the "send using ZModem" function locally.
I think the host I was on at the time (which appears to have been some
Solaris) also offered XModem and YModem variants as [rs][xy], but I
never used those because someone had at some point told me that ZModem
was better. :-)
--
✍ Michael Kjörling 🏡 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-11 0:22 ` [TUHS] " Clem Cole
@ 2022-12-11 2:37 ` segaloco via TUHS
2022-12-11 13:59 ` Michael Kjörling
1 sibling, 0 replies; 25+ messages in thread
From: segaloco via TUHS @ 2022-12-11 2:37 UTC (permalink / raw)
To: Clem Cole; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 5942 bytes --]
Luckily I can toss you my exact use-case with code.
https://gitlab.com/segaloco/riscv-bits/-/blob/master/util/sxj.c
Above is a little utility I spit out to very specifically perform XMODEM-CRC for the VisionFive RISC-V single-board computer. Word on the street is their recovery bootloader has a bug that prevents sx and other utilities from working properly. As far as I could tell, they don't send the standard ACK after each packet receipt, but instead some other character. I just opted to check for NAK and proceed if not received.
In any case, the above should achieve XMODEM-CRC transmission to the JH7100 RISC-V chip over UART.
The phenomenon I'm experiencing (and sorry, I'm not trying to turn this into Taylor UUCP troubleshooting, I promise) is that when using the ~$ escape, my code never receives the 'C' from the device to initiate XMODEM-CRC. I know it's reading local stdin still because if I type and submit a 'C', it picks up and starts transferring, likewise requiring me to submit a non-NAK character every packet. Otherwise it does work, so the stdout is going to the remote machine, but at least with ~$, the stdin from the serial line does stop showing on my screen, which made me think the redirect was happening, but it just seems to disappear off into the void (/dev/null?) while the local program reads local stdin and puts data out on the remote stdout. This does hold consistent with the manual verbiage for ~$, it only mentions stdout to remote, doesn't mention any ferrying of remote stdin into the local application being run.
I know my utility works because I've used it in the place of sx in GNU screen and it works like a charm. Plus it does send to the device if I provide the expected acknowledgement characters from my local machine in cu.
So this doesn't just turn into troubleshooting, all I hope to highlight here is getting stdin from the remote machine into a program launched via a ~ escape in cu, be it like the ~C option in BSD cu or ~+ option in Taylor. My curiosity is whether such a thing was in historic cu, and, if not, how it might have been accommodated otherwise. As always, thankful for the insight and feedback folks here provide!
- Matt G.
------- Original Message -------
On Saturday, December 10th, 2022 at 4:22 PM, Clem Cole <clemc@ccc.com> wrote:
> On Sat, Dec 10, 2022 at 2:39 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>
>> Good morning all. I've been doing some historical research on the UUCP cu utility this morning and have come across a little discrepancy between the various UNIX streams I was wondering if someone could illuminate.
>
> Maybe. see below....
>
>> So cu as of V7 supported the ~$ escape, a means of calling a local procedure and emitting stdout over the TTY line to the remote machine, all fine and good for packaging a character stream to emit. However, what I'm not finding in that age of documentation is any means of requesting std*in* from the TTY line as input to a local procedure (in essence running a text filter or handshake-driven protocols over cu). The context in which I'm researching this is integrating cu into my bare-metal SBC programming using XMODEM so I can rest a little easier my process is based on tools I'll probably find in most places.
>>
>> So old fashioned Mike Lesk-era cu only seems to do stdout redirect, but no stdin. I did some further digging and it looks like different UUCP implementations cracked this nut with different escapes, with BSD eventually going with ~C and Taylor UUCP opting for ~+. Checking the current illumos manual pages (for a SVR4-ish example) doesn't turn up any command for this. This is indicative of there never being an agreed-upon mechanism for doing this, although I could see this being a very useful mechanism.
>
> maybe -- need to see more of what your session was like. I never remember missing anything I needed.
>
>> What I'm curious about is if the lack of a bi-directional redirect in early cu is reflective of a lack of need for that sort of functionality at the time or that matters such as that were handled through a different mechanism.
>
> I'm not sure I get the question. We did all sorts of redirection and used/abused cu and its friends all the time. I suspect I'm not understanding what you are trying to do.
>
> From a history standpoint, cu(1) is just one of many programs in that family. In the mid/late 1970s, we used a program called 'connect' for Sixth Edition at CMU, IIRC the Purdue folks had a similar one which was called attach(1) and there was tip(1) which was from Case/UCB [Sam Leffler]. If you look in the USENIX archives, I bet you will find a 1/2 doz or so of programs in the ilk before V7. With V7 uucp. was delivered, so cu(1) began to make inroads as it had the advantage that it was set up to work on concert to uucico(8). Simply, V7 came out, and UUCP started to used and eventually the 'USENET' born, cu(1) sort of 'won' because most of the other programs tended to conflict with uucico(8) - plus since it was already there, people did not need something else. But if you had written one before V7, you often find sites sticking with what they had.
>
> There were a number of UNIX implementations of XMODEM and friends. The C version of Kermit (ckermit) was quite popular plus has connect(1)/tip(1)/cu(1) style functionality built into it, but .... IIRC does not obey the locks that uucico(8) wants so if you used it on TTYs that had a modem that uucico was trying grab, bad things happened. That said, in a microprocessor lab where you often dedicated. serial port to 'target' micro/pc, kermit worked well. My memory is there were also a bunch of two letter programs, rx/sx and rz/sz and the like. Frankly its been so long since I had any use for them, I've forgotten. Look in the both USENIX and the USENET source archives.
>
> Frankly, the last time I think I was trying to do this sort of thing, I was using Kermit.
>
> YMMV
> Clem
> ᐧ
[-- Attachment #2: Type: text/html, Size: 10094 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* [TUHS] Re: Stdin Redirect in Cu History/Alternatives?
2022-12-10 19:38 [TUHS] " segaloco via TUHS
@ 2022-12-11 0:22 ` Clem Cole
2022-12-11 2:37 ` segaloco via TUHS
2022-12-11 13:59 ` Michael Kjörling
0 siblings, 2 replies; 25+ messages in thread
From: Clem Cole @ 2022-12-11 0:22 UTC (permalink / raw)
To: segaloco; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 3731 bytes --]
On Sat, Dec 10, 2022 at 2:39 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
> Good morning all. I've been doing some historical research on the UUCP cu
> utility this morning and have come across a little discrepancy between the
> various UNIX streams I was wondering if someone could illuminate.
>
Maybe. see below....
>
> So cu as of V7 supported the ~$ escape, a means of calling a local
> procedure and emitting stdout over the TTY line to the remote machine, all
> fine and good for packaging a character stream to emit. However, what I'm
> not finding in that age of documentation is any means of requesting std*in*
> from the TTY line as input to a local procedure (in essence running a text
> filter or handshake-driven protocols over cu). The context in which I'm
> researching this is integrating cu into my bare-metal SBC programming using
> XMODEM so I can rest a little easier my process is based on tools I'll
> probably find in most places.
>
> So old fashioned Mike Lesk-era cu only seems to do stdout redirect, but no
> stdin. I did some further digging and it looks like different UUCP
> implementations cracked this nut with different escapes, with BSD
> eventually going with ~C and Taylor UUCP opting for ~+. Checking the
> current illumos manual pages (for a SVR4-ish example) doesn't turn up any
> command for this. This is indicative of there never being an agreed-upon
> mechanism for doing this, although I could see this being a very useful
> mechanism.
>
maybe -- need to see more of what your session was like. I never remember
missing anything I needed.
>
> What I'm curious about is if the lack of a bi-directional redirect in
> early cu is reflective of a lack of need for that sort of functionality at
> the time or that matters such as that were handled through a different
> mechanism.
I'm not sure I get the question. We did all sorts of redirection and
used/abused cu and its friends all the time. I suspect I'm not
understanding what you are trying to do.
From a history standpoint, cu(1) is just one of many programs in that
family. In the mid/late 1970s, we used a program called 'connect' for
Sixth Edition at CMU, IIRC the Purdue folks had a similar one which was
called attach(1) and there was tip(1) which was from Case/UCB [Sam
Leffler]. If you look in the USENIX archives, I bet you will find a 1/2
doz or so of programs in the ilk before V7. With V7 uucp. was delivered,
so cu(1) began to make inroads as it had the advantage that it was set up
to work on concert to uucico(8). Simply, V7 came out, and UUCP started to
used and eventually the 'USENET' born, cu(1) sort of 'won' because most of
the other programs tended to conflict with uucico(8) - plus since it was
already there, people did not need something else. But if you had written
one before V7, you often find sites sticking with what they had.
There were a number of UNIX implementations of XMODEM and friends. The C
version of Kermit (ckermit) was quite popular plus has
connect(1)/tip(1)/cu(1) style functionality built into it, but .... IIRC
does not obey the locks that uucico(8) wants so if you used it on TTYs that
had a modem that uucico was trying grab, bad things happened. That said,
in a microprocessor lab where you often dedicated. serial port to 'target'
micro/pc, kermit worked well. My memory is there were also a bunch of two
letter programs, rx/sx and rz/sz and the like. Frankly its been so long
since I had any use for them, I've forgotten. Look in the both USENIX and
the USENET source archives.
Frankly, the last time I think I was trying to do this sort of thing, I was
using Kermit.
YMMV
Clem
ᐧ
[-- Attachment #2: Type: text/html, Size: 6222 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2022-12-13 1:55 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-11 0:42 [TUHS] Re: Stdin Redirect in Cu History/Alternatives? Nelson H. F. Beebe
2022-12-11 2:16 ` Larry McVoy
2022-12-11 2:26 ` Warner Losh
2022-12-11 2:32 ` Larry McVoy
2022-12-11 2:33 ` Warner Losh
2022-12-11 2:39 ` Larry McVoy
2022-12-11 2:49 ` Bakul Shah
2022-12-11 3:10 ` Phil Budne
2022-12-11 4:17 ` Dan Cross
2022-12-11 4:45 ` Will Senn
2022-12-12 17:06 ` Doug McIntyre
-- strict thread matches above, loose matches on Subject: below --
2022-12-12 17:42 Nelson H. F. Beebe
2022-12-10 19:38 [TUHS] " segaloco via TUHS
2022-12-11 0:22 ` [TUHS] " Clem Cole
2022-12-11 2:37 ` segaloco via TUHS
2022-12-11 13:59 ` Michael Kjörling
2022-12-11 14:28 ` Steve Nickolas
2022-12-11 15:04 ` Dan Cross
2022-12-13 1:54 ` Larry McVoy
2022-12-11 17:18 ` Adam Thornton
2022-12-11 18:54 ` Michael Kjörling
2022-12-11 19:55 ` Dave Horsfall
2022-12-11 20:03 ` Larry McVoy
2022-12-11 23:22 ` segaloco via TUHS
2022-12-12 21:34 ` Dave Horsfall
2022-12-12 21:46 ` Chet Ramey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).