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.
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.
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. One thought I did have is that
there wasn't file locking at the time (right?) and so theoretically nothing would
prevent one from using a cu session on one terminal to send interactive commands and then
a second using fd redirects in the shell to run filters/protocols separately of the
interactive stream.
- Matt G.