From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12268 invoked from network); 11 Dec 2022 00:24:17 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 11 Dec 2022 00:24:17 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id C9077423B9; Sun, 11 Dec 2022 10:24:11 +1000 (AEST) Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) by minnie.tuhs.org (Postfix) with ESMTPS id 3D05D423B7 for ; Sun, 11 Dec 2022 10:24:05 +1000 (AEST) Received: by mail-ua1-f41.google.com with SMTP id v21so2282786uam.1 for ; Sat, 10 Dec 2022 16:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=T9knMNClzaGcEhId/WW9+V+z6wV+RoP0s4ea3F8ESk0=; b=Lxh7jzKwh+h0JnV2nOwXj0/WRJygrxmOEtoc6mr6ZSd/nNWWHX+RoBril6pAXrGIXX WNZAP1FJ/3p042VcVjkKmDd60fndyHWrot0Jxy+fKAa0hytQ2vBCK5XN/SZCZcKUQJMj /gQnjrzSvGaM0cCQX9VKySqQvOUIMs+wTnlWw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=T9knMNClzaGcEhId/WW9+V+z6wV+RoP0s4ea3F8ESk0=; b=l/83p4fVfhwhPnx8T+We76B/nVpO9FieWmWoCoYhbSWSgjCs1jquhtyktsvDAxUPFR X02L5UK63qMOOalfnwEEhpil1GpOMqXKHL87OR2XUbNpWyPyuCNx/IqXzuqGcZTOfgVp 2W1dUfLgpjgJ9z5bGvL97Eeeu/OVxTeNqTyoRKqA4lOo9aOjt6SkOoF/46QA8GaRh+fc ZyC6fLzSj1xvlkPtH4Bx4cVdD6eg9xWI4YQaM6M8gZY3JVGsTX3sSJfVPaU3xuPplaLE lUvK4/pz92c/aywXU+IsBdMT22WBMfsIsSrFQ0QSAt5pfknv/SbIwupGxVOJF1O4tyR2 8R2Q== X-Gm-Message-State: ANoB5pnpATzJoHrnBaBN+g+O5jCinihx0BAe052PgiWOLzyaddQaWo9C Ko8dMiYjb3Js7YQZrRyEP/MbnHzMmVyPVZvfVl30hg== X-Google-Smtp-Source: AA0mqf4wYFEIDn5pvoP8gxIb48lN3zrU4RDHX4Kt3hTMgaJc3e1fXVq2l4W+GpUXIFwbyGBQvulh1kro+DPDMYcHDL8= X-Received: by 2002:ab0:76d9:0:b0:419:1a4a:cefa with SMTP id w25-20020ab076d9000000b004191a4acefamr29384944uaq.66.1670718183935; Sat, 10 Dec 2022 16:23:03 -0800 (PST) MIME-Version: 1.0 References: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> In-Reply-To: <9QJtlCA0hfDuNuwOqorx1uC2eSGOiIBu0hgsVAaKclEWUw4Gi9PAjJoZgcOF7W6rRCw4XqM3wBZMavgF_HEH4GR2WuczKF5w_tZAjAXgzlE=@protonmail.com> From: Clem Cole Date: Sat, 10 Dec 2022 19:22:35 -0500 Message-ID: To: segaloco Content-Type: multipart/alternative; boundary="000000000000dfa72005ef8263e1" Message-ID-Hash: Z4ACWGY4SHKUE2XFU55INDQ4P6BCRHD3 X-Message-ID-Hash: Z4ACWGY4SHKUE2XFU55INDQ4P6BCRHD3 X-MailFrom: clemc@ccc.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Stdin Redirect in Cu History/Alternatives? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000dfa72005ef8263e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 10, 2022 at 2:39 PM segaloco via TUHS wrote: > Good morning all. I've been doing some historical research on the UUCP c= u > utility this morning and have come across a little discrepancy between th= e > 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, al= l > 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*i= n* > from the TTY line as input to a local procedure (in essence running a tex= t > filter or handshake-driven protocols over cu). The context in which I'm > researching this is integrating cu into my bare-metal SBC programming usi= ng > 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 n= o > 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 a= t > 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 =E1=90=A7 --000000000000dfa72005ef8263e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On S= at, Dec 10, 2022 at 2:39 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
Good morning all.=C2=A0= I've been doing some historical research on the UUCP cu utility this m= orning and have come across a little discrepancy between the various UNIX s= treams I was wondering if someone could illuminate.
=
Maybe. see below....=C2=A0

So cu as of V7 supported the ~$ escape, a means of calling a local procedur= e and emitting stdout over the TTY line to the remote machine, all fine and= good for packaging a character stream to emit.=C2=A0 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 tex= t filter or handshake-driven protocols over cu).=C2=A0 The context in which= I'm researching this is integrating cu into my bare-metal SBC programm= ing 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.=C2=A0 I did some further digging and it looks like different UUCP im= plementations cracked this nut with different escapes, with BSD eventually = going with ~C and Taylor UUCP opting for ~+.=C2=A0 Checking the current ill= umos manual pages (for a SVR4-ish example) doesn't turn up any command = for this.=C2=A0 This is indicative of there never being an agreed-upon mech= anism for doing this, although I could see this being a very useful mechani= sm.
maybe -- need t= o see more of=C2=A0what your session was like.=C2=A0 I never remember missi= ng anything I needed.

What I'm curious about is if the lack of a bi-directional redirect in e= arly cu is reflective of a lack of need for that sort of functionality at t= he time or that matters such as that were handled through a different mecha= nism.=C2=A0
I'm not = sure I get the question.=C2=A0 We did all sorts of redirection and used/abu= sed cu and its friends all the time.=C2=A0 =C2=A0 I suspect I'm not und= erstanding what you are trying to do.

From a history standpoi= nt, cu(1) is just one of many programs in that family.=C2=A0 In the mid/lat= e 1970s, we used a program called 'connect' for Sixth Edition at CM= U, IIRC the Purdue folks had a similar one which was called attach(1) and t= here was tip(1) which was from Case/UCB [Sam Leffler].=C2=A0 If you look in= the USENIX archives, I bet you will find a 1/2 doz or so of programs in th= e ilk before V7.=C2=A0 With V7 uucp. was delivered, so=C2=A0cu(1) began to = make inroads as it had the advantage that it was set up to work on concert = to uucico(8).=C2=A0Simply, V7 came out, and UUCP started to used and eventu= ally the 'USENET' born, cu(1) sort of 'won' because most of= the other programs tended to conflict with uucico(8) -=C2=A0 plus since it= was already there, people did not need something else.=C2=A0 =C2=A0But 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 fri= ends.=C2=A0 The C version of Kermit=C2=A0 (ckermit) was quite popular plus = has connect(1)/tip(1)/cu(1) style functionality built into it, but ....=C2= =A0 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.=C2= =A0 =C2=A0That said, in a microprocessor lab where you often dedicated. ser= ial port to 'target' micro/pc, kermit worked well.=C2=A0 =C2=A0My m= emory is there were also a bunch=C2=A0of two letter programs, rx/sx and rz/= sz and the like.=C2=A0 Frankly its been so long since I had any use for the= m, I've forgotten. Look in the both USENIX and the USENET source archiv= es.

Frankly, the last time I think I was trying to do this sort of= =C2=A0thing, I was using Kermit.
YMMV
Clem
3D""=E1=90=A7
--000000000000dfa72005ef8263e1--