[TUHS] Stdin Redirect in Cu History/Alternatives?

[segaloco via TUHS]

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 at ccc.com> wrote:

> On Sat, Dec 10, 2022 at 2:39 PM segaloco via TUHS <tuhs at 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
> ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20221211/25461916/attachment.htm>