[TUHS] Re: Stdin Redirect in Cu History/Alternatives?

[Clem Cole <clemc@ccc.com>]

[-- 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 --]