11 Dec
2022
11 Dec
'22
8:37 a.m.
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(a)ccc.com> wrote:
On Sat, Dec 10, 2022 at 2:39 PM segaloco via TUHS
<tuhs(a)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
ᐧ