[TUHS] v7 uucp debugging help requested

[TUHS] v7 uucp debugging help requested

[Adam Thornton]

[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]

(if this is better suited for COFF, that'd be fine too)

I've been trying to set up UUCP on my V7 system and its raspberry Pi host.
This plus the "s" editor (already working) are really all that's needed to
make this something pretty close to a daily driver, if all I wanted to do
was write text files (which in some sense is all my job _is_, but to be
fair I get a much more immediate feedback loop in my current environment).

I was following
https://github.com/jwbrase/pdp11-tools/blob/master/howtos/V7%20UUCP%20Installation%20Guide.pdf
more or less--I had already rebuilt v7 with the DZ terminal driver and was
using it for interactive sessions (albeit, before I started trying to get
UUCP running, with 7-bit line discipline--but I've since changed that).

I have 16 DZ lines, I've set them to 8-bit mode.  They're working fine,
because I can use them for terminal sessions.

I've built UUCP, set a node name, and set it up on the pi.

I can execute uucico to send files, and it, frustratingly, almost works.

From the Pi side, I see (with uulog):

uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP)
uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful
uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful (protocol
'g' sending packet/window 64/3 receiving 64/7)
uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending
/home/adam/git/simh/sim_scsi.h (6780 bytes)
uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting for
packet
uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent 86,
resent 6, received 1
uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0,
order 0, remote rejects 0
uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds 5440
bytes 19 bps)

So it's clearly logging in, and if I telnet in directly, the v7 end is
starting uucico as expected:

login: pi-uucp
Password:
Shere

uulog -x on the v7 side has no output, and nothing ever appears in the
spool directory, which I suspect is a direct result of the timeout waiting
for packet.

So my question is, what else do I do to debug this?  Clearly the pi (Taylor
UUCP) side is expecting something else--maybe an acknowledgement?--from the
v7 side to let it know the transmission was successful.

Any help would be appreciated.

Adam

[-- Attachment #2: Type: text/html, Size: 2859 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]

On Fri, Jul 3, 2020 at 4:54 PM Adam Thornton <athornton@gmail.com> wrote:

> (if this is better suited for COFF, that'd be fine too)
>
> I've been trying to set up UUCP on my V7 system and its raspberry Pi
> host.  This plus the "s" editor (already working) are really all that's
> needed to make this something pretty close to a daily driver, if all I
> wanted to do was write text files (which in some sense is all my job _is_,
> but to be fair I get a much more immediate feedback loop in my current
> environment).
>
> I was following
> https://github.com/jwbrase/pdp11-tools/blob/master/howtos/V7%20UUCP%20Installation%20Guide.pdf
> more or less--I had already rebuilt v7 with the DZ terminal driver and was
> using it for interactive sessions (albeit, before I started trying to get
> UUCP running, with 7-bit line discipline--but I've since changed that).
>
> I have 16 DZ lines, I've set them to 8-bit mode.  They're working fine,
> because I can use them for terminal sessions.
>
As a long time UUCP person on PDP-11's, "Danger Will Robinson."

Just for grins and giggles on the V7/PDP-11 side, try it over a DH  (VH
driver in simh) emulation (or even a KL/DL - although the
simulated interrupts will be a mother).  That said, the VH driver is a not
exactly a DH as I understand it, its the later QBUS version which was
similar but different.   It's been on my list of things I want to chase
down at some point to make work to get it closer to the original.

FYI: Running UUCP over real DZ's was always troublesome.  There were a ton
of updates/patches done post the original V7 release in the DZ drivers to
make them play better.   Most of us that ran large UUCP set up in the old
days, installed ABLE DMAX (DH/DM) that were a single board DH replacement -
they are DMA, and buffered (and supported proper modem control which the
DZ's don't - although later UCB work on the driver sort of faked it enough
to make to it work for basic dial-up use reasonably reliably).

[-- Attachment #2: Type: text/html, Size: 3377 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Grant Taylor via TUHS]

[-- Attachment #1: Type: text/plain, Size: 2309 bytes --]

On 7/3/20 2:52 PM, Adam Thornton wrote:
> I've built UUCP, set a node name, and set it up on the pi.
> 
> I can execute uucico to send files, and it, frustratingly, almost works.

Which system are you referring to here?  The Pi or V7?

>  From the Pi side, I see (with uulog):
> 
> uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP)
> uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful
> uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful 
> (protocol 'g' sending packet/window 64/3 receiving 64/7)
> uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending 
> /home/adam/git/simh/sim_scsi.h (6780 bytes)
> uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting 
> for packet
> uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent 
> 86, resent 6, received 1

I'm a little surprised that you're trying to use the 'g' protocol to 
talk to v7.  I thought the 'g' protocol came out later for TCP over 
Ethernet connections.  As such I wonder if UUCP on v7 supports the 'g' 
protocol.

I think that Clem knows a LOT more about this than I do.

I'm ignorantly asking questions.

> uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0, 
> order 0, remote rejects 0
> uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds 
> 5440 bytes 19 bps)
> 
> So it's clearly logging in, and if I telnet in directly, the v7 end is 
> starting uucico as expected:
> 
> login: pi-uucp
> Password:
> Shere

Shouldn't that be something more like the following?

Shere=v7

What does 'uuname -l' (or '--local') show?  (I'm much more familiar with 
Taylor UUCP than I am the UUCP in v7.

> uulog -x on the v7 side has no output, and nothing ever appears in the 
> spool directory, which I suspect is a direct result of the timeout 
> waiting for packet.
> 
> So my question is, what else do I do to debug this?  Clearly the pi 
> (Taylor UUCP) side is expecting something else--maybe an 
> acknowledgement?--from the v7 side to let it know the transmission was 
> successful.
> 
> Any help would be appreciated.

I've not messed with this particular problem in probably 2 years and 
I've forgotten more than comments above.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 2682 bytes --]

Grant - The g (greg’s protocol) is correct. IIRC that’s the only line
protocol Dan distributed in the V7 original code base.

On Fri, Jul 3, 2020 at 6:46 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On 7/3/20 2:52 PM, Adam Thornton wrote:
> > I've built UUCP, set a node name, and set it up on the pi.
> >
> > I can execute uucico to send files, and it, frustratingly, almost works.
>
> Which system are you referring to here?  The Pi or V7?
>
> >  From the Pi side, I see (with uulog):
> >
> > uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP)
> > uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful
> > uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful
> > (protocol 'g' sending packet/window 64/3 receiving 64/7)
> > uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending
> > /home/adam/git/simh/sim_scsi.h (6780 bytes)
> > uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting
> > for packet
> > uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent
> > 86, resent 6, received 1
>
> I'm a little surprised that you're trying to use the 'g' protocol to
> talk to v7.  I thought the 'g' protocol came out later for TCP over
> Ethernet connections.  As such I wonder if UUCP on v7 supports the 'g'
> protocol.
>
> I think that Clem knows a LOT more about this than I do.
>
> I'm ignorantly asking questions.
>
> > uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0,
> > order 0, remote rejects 0
> > uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds
> > 5440 bytes 19 bps)
> >
> > So it's clearly logging in, and if I telnet in directly, the v7 end is
> > starting uucico as expected:
> >
> > login: pi-uucp
> > Password:
> > Shere
>
> Shouldn't that be something more like the following?
>
> Shere=v7
>
> What does 'uuname -l' (or '--local') show?  (I'm much more familiar with
> Taylor UUCP than I am the UUCP in v7.
>
> > uulog -x on the v7 side has no output, and nothing ever appears in the
> > spool directory, which I suspect is a direct result of the timeout
> > waiting for packet.
> >
> > So my question is, what else do I do to debug this?  Clearly the pi
> > (Taylor UUCP) side is expecting something else--maybe an
> > acknowledgement?--from the v7 side to let it know the transmission was
> > successful.
> >
> > Any help would be appreciated.
>
> I've not messed with this particular problem in probably 2 years and
> I've forgotten more than comments above.
>
>
>
> --
> Grant. . . .
> unix || die
>
> --
Sent from a handheld expect more typos than usual

[-- Attachment #2: Type: text/html, Size: 3418 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 2670 bytes --]

Grant. I wrote e for Ethernet based ( ip/ tcp ) connections at Masscomp so
we didn’t have hack the mailer at time.

On Fri, Jul 3, 2020 at 6:46 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On 7/3/20 2:52 PM, Adam Thornton wrote:
> > I've built UUCP, set a node name, and set it up on the pi.
> >
> > I can execute uucico to send files, and it, frustratingly, almost works.
>
> Which system are you referring to here?  The Pi or V7?
>
> >  From the Pi side, I see (with uulog):
> >
> > uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP)
> > uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful
> > uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful
> > (protocol 'g' sending packet/window 64/3 receiving 64/7)
> > uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending
> > /home/adam/git/simh/sim_scsi.h (6780 bytes)
> > uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting
> > for packet
> > uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent
> > 86, resent 6, received 1
>
> I'm a little surprised that you're trying to use the 'g' protocol to
> talk to v7.  I thought the 'g' protocol came out later for TCP over
> Ethernet connections.  As such I wonder if UUCP on v7 supports the 'g'
> protocol.
>
> I think that Clem knows a LOT more about this than I do.
>
> I'm ignorantly asking questions.
>
> > uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0,
> > order 0, remote rejects 0
> > uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds
> > 5440 bytes 19 bps)
> >
> > So it's clearly logging in, and if I telnet in directly, the v7 end is
> > starting uucico as expected:
> >
> > login: pi-uucp
> > Password:
> > Shere
>
> Shouldn't that be something more like the following?
>
> Shere=v7
>
> What does 'uuname -l' (or '--local') show?  (I'm much more familiar with
> Taylor UUCP than I am the UUCP in v7.
>
> > uulog -x on the v7 side has no output, and nothing ever appears in the
> > spool directory, which I suspect is a direct result of the timeout
> > waiting for packet.
> >
> > So my question is, what else do I do to debug this?  Clearly the pi
> > (Taylor UUCP) side is expecting something else--maybe an
> > acknowledgement?--from the v7 side to let it know the transmission was
> > successful.
> >
> > Any help would be appreciated.
>
> I've not messed with this particular problem in probably 2 years and
> I've forgotten more than comments above.
>
>
>
> --
> Grant. . . .
> unix || die
>
> --
Sent from a handheld expect more typos than usual

[-- Attachment #2: Type: text/html, Size: 3409 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Adam Thornton]

[-- Attachment #1: Type: text/plain, Size: 2811 bytes --]

v7 UUCP has no uuname command: I get uucp, uux, uuxqt, uucico, uulog, and
uuclean.  The makefile also includes uurecover but it's not part of the
default targets.

uucp, uulog, and uux go in /bin, the others in /usr/lib/uucp.

It does look like there are debug statements in cico.c; I'll try connecting
from the pi side manually and invoking uucico -x 7 and seeing what happens.

Adam



On Fri, Jul 3, 2020 at 3:46 PM Grant Taylor via TUHS <tuhs@minnie.tuhs.org>
wrote:

> On 7/3/20 2:52 PM, Adam Thornton wrote:
> > I've built UUCP, set a node name, and set it up on the pi.
> >
> > I can execute uucico to send files, and it, frustratingly, almost works.
>
> Which system are you referring to here?  The Pi or V7?
>
> >  From the Pi side, I see (with uulog):
> >
> > uucico v7 - (2020-07-03 08:11:34.97 23106) Calling system v7 (port TCP)
> > uucico v7 - (2020-07-03 08:11:42.25 23106) Login successful
> > uucico v7 - (2020-07-03 08:11:44.44 23106) Handshake successful
> > (protocol 'g' sending packet/window 64/3 receiving 64/7)
> > uucico v7 adam (2020-07-03 08:11:51.61 23106) Sending
> > /home/adam/git/simh/sim_scsi.h (6780 bytes)
> > uucico v7 adam (2020-07-03 08:16:21.79 23106) ERROR: Timed out waiting
> > for packet
> > uucico v7 - (2020-07-03 08:16:21.80 23106) Protocol 'g' packets: sent
> > 86, resent 6, received 1
>
> I'm a little surprised that you're trying to use the 'g' protocol to
> talk to v7.  I thought the 'g' protocol came out later for TCP over
> Ethernet connections.  As such I wonder if UUCP on v7 supports the 'g'
> protocol.
>
> I think that Clem knows a LOT more about this than I do.
>
> I'm ignorantly asking questions.
>
> > uucico v7 - (2020-07-03 08:16:21.80 23106) Errors: header 2, checksum 0,
> > order 0, remote rejects 0
> > uucico v7 - (2020-07-03 08:16:22.51 23106) Call complete (283 seconds
> > 5440 bytes 19 bps)
> >
> > So it's clearly logging in, and if I telnet in directly, the v7 end is
> > starting uucico as expected:
> >
> > login: pi-uucp
> > Password:
> > Shere
>
> Shouldn't that be something more like the following?
>
> Shere=v7
>
> What does 'uuname -l' (or '--local') show?  (I'm much more familiar with
> Taylor UUCP than I am the UUCP in v7.
>
> > uulog -x on the v7 side has no output, and nothing ever appears in the
> > spool directory, which I suspect is a direct result of the timeout
> > waiting for packet.
> >
> > So my question is, what else do I do to debug this?  Clearly the pi
> > (Taylor UUCP) side is expecting something else--maybe an
> > acknowledgement?--from the v7 side to let it know the transmission was
> > successful.
> >
> > Any help would be appreciated.
>
> I've not messed with this particular problem in probably 2 years and
> I've forgotten more than comments above.
>
>
>
> --
> Grant. . . .
> unix || die
>
>

[-- Attachment #2: Type: text/html, Size: 3662 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 350 bytes --]

On Sat, Jul 4, 2020 at 3:34 PM Adam Thornton <athornton@gmail.com> wrote:

> v7 UUCP has no uuname command: I get uucp, uux, uuxqt, uucico, uulog, and
> uuclean.
>
Yep - that was BSDism, the version 3BSD -- uuname.c
<https://minnie.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/src/cmd/uucp/uuname.c>
should
just recompile and manpage is very google-able.

[-- Attachment #2: Type: text/html, Size: 909 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Adam Thornton]

[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

Yup, and the output is exactly what I would expect:

# ./uuname
Format
16bitpi
# ./uuname -l
v7

That is, locally I am v7, and the only remote host I know about is 16bitpi.

Adam

On Sat, Jul 4, 2020 at 1:02 PM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Sat, Jul 4, 2020 at 3:34 PM Adam Thornton <athornton@gmail.com> wrote:
>
>> v7 UUCP has no uuname command: I get uucp, uux, uuxqt, uucico, uulog, and
>> uuclean.
>>
> Yep - that was BSDism, the version 3BSD -- uuname.c
> <https://minnie.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/src/cmd/uucp/uuname.c> should
> just recompile and manpage is very google-able.
>

[-- Attachment #2: Type: text/html, Size: 1558 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Adam Thornton]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

Jon Brase on the PiDP-11 list solved the problem for me.  For future
reference, you need to dedicate a tty line/host TCP port to the UUCP line,
and tell simh to use it notelnet.

e.g.:

set dz en
set dz lines=16
att -m dz 1107
# UUCP needs 8 bits
set dz 8b
att dz -am line=4,1729;notelnet

And then on the Taylor UUCP side, point the UUCP port at localhost:1729
(rather than 1107).

Adam

On Sat, Jul 4, 2020 at 2:58 PM Adam Thornton <athornton@gmail.com> wrote:

> Yup, and the output is exactly what I would expect:
>
> # ./uuname
> Format
> 16bitpi
> # ./uuname -l
> v7
>
> That is, locally I am v7, and the only remote host I know about is 16bitpi.
>
> Adam
>
> On Sat, Jul 4, 2020 at 1:02 PM Clem Cole <clemc@ccc.com> wrote:
>
>>
>>
>> On Sat, Jul 4, 2020 at 3:34 PM Adam Thornton <athornton@gmail.com> wrote:
>>
>>> v7 UUCP has no uuname command: I get uucp, uux, uuxqt, uucico, uulog,
>>> and uuclean.
>>>
>> Yep - that was BSDism, the version 3BSD -- uuname.c
>> <https://minnie.tuhs.org/cgi-bin/utree.pl?file=3BSD/usr/src/cmd/uucp/uuname.c> should
>> just recompile and manpage is very google-able.
>>
>

[-- Attachment #2: Type: text/html, Size: 2479 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

On Fri, Jul 3, 2020 at 4:54 PM Adam Thornton <athornton@gmail.com> wrote:


> I've been trying to set up UUCP on my V7 system and its raspberry Pi
> host.  This plus the "s" editor (already working)
>

What is this "s" editor?  The v7 man pages say nothing about it, and of
course Dr. Google is equally unhelpful.


John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
We call nothing profound that is not wittily expressed.
        --Northrop Frye (improved)

[-- Attachment #2: Type: text/html, Size: 1027 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Adam Thornton]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

The "s" editor is written by Webb Miller and appears in his book "A
Software Tools Sampler."  There was a discussion about it...here, or COFF,
or cctalk, or the PiDP-11 mailing list....a few months ago.  Someone had
already done the lifting to make it classic v7-compatible, but I don't
remember who.

Its interface is very close to vi, but it is quite compact and works well
on v7.

I have a fork of it that has the needed tweaks for PDP-11 v7 up at
https://github.com/athornton/s .

Since I find ed thoroughly unpleasant to use, having a screen editor was a
must for me to use v7 for any length of time, and s fills that role rather
nicely.

Adam

On Fri, Jul 3, 2020 at 3:50 PM John Cowan <cowan@ccil.org> wrote:

>
> On Fri, Jul 3, 2020 at 4:54 PM Adam Thornton <athornton@gmail.com> wrote:
>
>
>> I've been trying to set up UUCP on my V7 system and its raspberry Pi
>> host.  This plus the "s" editor (already working)
>>
>
> What is this "s" editor?  The v7 man pages say nothing about it, and of
> course Dr. Google is equally unhelpful.
>
>
> John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
> We call nothing profound that is not wittily expressed.
>         --Northrop Frye (improved)
>
>

[-- Attachment #2: Type: text/html, Size: 2260 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

On Sat, Jul 4, 2020 at 12:33 PM Adam Thornton <athornton@gmail.com> wrote:

The "s" editor is written by Webb Miller and appears in his book "A
> Software Tools Sampler."
>

Wow, I never knew about this book, though I know ST and STP well, and used
ST on RSX-11/M+ and VAX/VMS for $EMPLOYER in the 1980s.  Is the rest of the
source code for the book available online anywhere?

Jez Higgins is rewriting the STP tools into modern C++.  His blog posts are
at <https://www.jezuk.co.uk/tags/software-tools-in-c++.html> and the code
is at <https://github.com/jezhiggins/stiX>.  He's rewritten the tools in
chapters 1 and 2 and part of 3.

Since I find ed thoroughly unpleasant to use, having a screen editor was a
> must for me to use v7 for any length of time, and s fills that role rather
> nicely.
>

Gotcha.  I actually like line editors (you can't mung your file so
thoroughly with a single stray keystroke), but I'm willing to trade a
little standardosity for additional convenience, so I do almost all my
editing of prose and programs in `ex`, occasionally dropping into vi-mode
for matching open and close markers in Lisp and XML.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
If you have ever wondered if you are in hell, it has been said, then
you are on a well-traveled road of spiritual inquiry.  If you are
absolutely sure you are in hell, however, then you must be on the Cross
Bronx Expressway.  --Alan Feuer, New York Times, 2002-09-20

[-- Attachment #2: Type: text/html, Size: 2449 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Jon Forrest]

On 7/4/2020 11:34 AM, John Cowan wrote:

>     The "s" editor is written by Webb Miller and appears in his book "A
>     Software Tools Sampler." 
> 
> 
> Wow, I never knew about this book, though I know ST and STP well, and 
> used ST on RSX-11/M+ and VAX/VMS for $EMPLOYER in the 1980s.

As I mentioned last time this topic came up, I have a copy of this
book for sale. Please contact me offlist if you're interested.

Jon

Re: [TUHS] v7 uucp debugging help requested

[Adam Thornton]

[-- Attachment #1: Type: text/plain, Size: 1810 bytes --]

I don't know of the other tools being available, but...it does look like I
will have this book on Interlibrary Loan for .... quite a while longer.

No promises, but if I get bored this summer.....

Adam

On Sat, Jul 4, 2020 at 11:34 AM John Cowan <cowan@ccil.org> wrote:

>
>
> On Sat, Jul 4, 2020 at 12:33 PM Adam Thornton <athornton@gmail.com> wrote:
>
> The "s" editor is written by Webb Miller and appears in his book "A
>> Software Tools Sampler."
>>
>
> Wow, I never knew about this book, though I know ST and STP well, and used
> ST on RSX-11/M+ and VAX/VMS for $EMPLOYER in the 1980s.  Is the rest of the
> source code for the book available online anywhere?
>
> Jez Higgins is rewriting the STP tools into modern C++.  His blog posts
> are at <https://www.jezuk.co.uk/tags/software-tools-in-c++.html> and the
> code is at <https://github.com/jezhiggins/stiX>.  He's rewritten the
> tools in chapters 1 and 2 and part of 3.
>
> Since I find ed thoroughly unpleasant to use, having a screen editor was a
>> must for me to use v7 for any length of time, and s fills that role rather
>> nicely.
>>
>
> Gotcha.  I actually like line editors (you can't mung your file so
> thoroughly with a single stray keystroke), but I'm willing to trade a
> little standardosity for additional convenience, so I do almost all my
> editing of prose and programs in `ex`, occasionally dropping into vi-mode
> for matching open and close markers in Lisp and XML.
>
>
>
> John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
> If you have ever wondered if you are in hell, it has been said, then
> you are on a well-traveled road of spiritual inquiry.  If you are
> absolutely sure you are in hell, however, then you must be on the Cross
> Bronx Expressway.  --Alan Feuer, New York Times, 2002-09-20
>
>

[-- Attachment #2: Type: text/html, Size: 3142 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Dave Horsfall]

On Sat, 4 Jul 2020, Adam Thornton wrote:

> Since I find ed thoroughly unpleasant to use, having a screen editor was 
> a must for me to use v7 for any length of time, and s fills that role 
> rather nicely.

A boss of mine insisted that we all learned "ed", because one day it might 
be the only editor available to you after a crash; he was right...

-- Dave

Re: [TUHS] v7 uucp debugging help requested

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

On Sun, Jul 5, 2020, 10:14 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Sat, 4 Jul 2020, Adam Thornton wrote:
>
> > Since I find ed thoroughly unpleasant to use, having a screen editor was
> > a must for me to use v7 for any length of time, and s fills that role
> > rather nicely.
>
> A boss of mine insisted that we all learned "ed", because one day it might
> be the only editor available to you after a crash; he was right...
>

I should do that... So far I've managed to get by with sed :)

Warner

>

[-- Attachment #2: Type: text/html, Size: 1096 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[arnold]

Warner Losh <imp@bsdimp.com> wrote:

> On Sun, Jul 5, 2020, 10:14 PM Dave Horsfall <dave@horsfall.org> wrote:
>
> > On Sat, 4 Jul 2020, Adam Thornton wrote:
> >
> > > Since I find ed thoroughly unpleasant to use, having a screen editor was
> > > a must for me to use v7 for any length of time, and s fills that role
> > > rather nicely.
> >
> > A boss of mine insisted that we all learned "ed", because one day it might
> > be the only editor available to you after a crash; he was right...
> >
>
> I should do that... So far I've managed to get by with sed :)
>
> Warner
>
> >

If you know the ex subset of vi, you know most of what you need to
know to use ed ...

Arnold

Re: [TUHS] v7 uucp debugging help requested

[Michael Usher via TUHS]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

I actually like ed and sam.  I find it "soothing" to be able to manipulate
text almost "programmatically"....

As an undergrad at USyd EE Dept, the VT100s in the computer lab were often
all taken, but there were a few LA30s still hooked up and no-one wanted to
use them.  I learned how to optimally enter, compile and debug code through
a paper interface.  It was VMS of course at EE, but when I started using
the Unix systems at CS a year later, the 11/750 was so heavily loaded that
"ed" was the best choice for getting assignments done quickly.  Line
editors were also much more pleasant to use over slow modem connections.  I
had a 28.8k modem but the dialup pool rarely got you a high speed
connection...

But back to the original topic...  Has the MHSnet code made it into the
public domain?

Michael

On Sun, Jul 5, 2020 at 11:52 PM <arnold@skeeve.com> wrote:

> Warner Losh <imp@bsdimp.com> wrote:
>
> > On Sun, Jul 5, 2020, 10:14 PM Dave Horsfall <dave@horsfall.org> wrote:
> >
> > > On Sat, 4 Jul 2020, Adam Thornton wrote:
> > >
> > > > Since I find ed thoroughly unpleasant to use, having a screen editor
> was
> > > > a must for me to use v7 for any length of time, and s fills that role
> > > > rather nicely.
> > >
> > > A boss of mine insisted that we all learned "ed", because one day it
> might
> > > be the only editor available to you after a crash; he was right...
> > >
> >
> > I should do that... So far I've managed to get by with sed :)
> >
> > Warner
> >
> > >
>
> If you know the ex subset of vi, you know most of what you need to
> know to use ed ...
>
> Arnold
>


-- 
Michael Usher
Senior Wireless Network Engineer
University of California, Santa Cruz
musher@ucsc.edu        831-459-3697

[-- Attachment #2: Type: text/html, Size: 2662 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

I always recommend doing the exercises in Rob and Brian's UPE on ed because
then everything else makes sense, like sed or any other editor.   Plus you
get the advantage you point out, and the reality is that so many
simpler editors (like edlin) have similar functionality, it means you can
get something done, just about anywhere.

On Mon, Jul 6, 2020 at 12:14 AM Dave Horsfall <dave@horsfall.org> wrote:

> On Sat, 4 Jul 2020, Adam Thornton wrote:
>
> > Since I find ed thoroughly unpleasant to use, having a screen editor was
> > a must for me to use v7 for any length of time, and s fills that role
> > rather nicely.
>
> A boss of mine insisted that we all learned "ed", because one day it might
> be the only editor available to you after a crash; he was right...
>
> -- Dave
>

[-- Attachment #2: Type: text/html, Size: 1203 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

I fall back to ed or tr when I hit the bug in vim that prevents you from
inserting a newline with the s command (it inserts a NUL instead).

On Mon, Jul 6, 2020 at 9:59 AM Clem Cole <clemc@ccc.com> wrote:

> I always recommend doing the exercises in Rob and Brian's UPE on ed
> because then everything else makes sense, like sed or any other editor.
>  Plus you get the advantage you point out, and the reality is that so many
> simpler editors (like edlin) have similar functionality, it means you can
> get something done, just about anywhere.
>
> On Mon, Jul 6, 2020 at 12:14 AM Dave Horsfall <dave@horsfall.org> wrote:
>
>> On Sat, 4 Jul 2020, Adam Thornton wrote:
>>
>> > Since I find ed thoroughly unpleasant to use, having a screen editor
>> was
>> > a must for me to use v7 for any length of time, and s fills that role
>> > rather nicely.
>>
>> A boss of mine insisted that we all learned "ed", because one day it
>> might
>> be the only editor available to you after a crash; he was right...
>>
>> -- Dave
>>
>

[-- Attachment #2: Type: text/html, Size: 1698 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[arnold]

John Cowan <cowan@ccil.org> wrote:

> I fall back to ed or tr when I hit the bug in vim that prevents you from
> inserting a newline with the s command (it inserts a NUL instead).

Huh? I've never seen this, in over 20 years of using vim. To
insert a newline just use

	s/foobar/foo^V^Mbar/

where ^V^M are Control-V Control-M.

Arnold

Re: [TUHS] v7 uucp debugging help requested

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

On Mon, Jul 6, 2020 at 3:19 PM <arnold@skeeve.com> wrote:

Huh? I've never seen this, in over 20 years of using vim. To
> insert a newline just use
>
>         s/foobar/foo^V^Mbar/
>
> where ^V^M are Control-V Control-M.
>

I never thought of that; I've always tried what works in ed, namely:

s/foobar/foo\
bar

and that gives me

foo^@bar

I call that a bug.  (This is vim 8.1).

It certainly wouldn't occur to me to use ^V^M, anyhow:  ^V^J would seem
more reasonable, but ^V is ignored in that context.

Before vim 7 there was a bug so bad I had to use nvi (and, often enough,
compile it from source): at that time, undo undid everything back to the
last action in vi-mode.  If you had never been in vi-mode (as I usually had
not) it undid everything back to the last file-loading command!  That one
made me grind my teeth a lot.  Even now I habitually write before undoing,
just in case.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
A male Jang appeared at my side.  "Get a grip on yourself," he said.
"Get a grip on your graks," I suggested.  --Tanith Lee, Drinking Sapphire
Wine

[-- Attachment #2: Type: text/html, Size: 1896 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

On Mon, Jul 6, 2020 at 3:36 PM John Cowan <cowan@ccil.org> wrote:

I call that a bug.  (This is vim 8.1).
>

To be precise, this is now https://github.com/vim/vim/issues/6411.  Feel
free to upvote.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE
WUGGUMS

[-- Attachment #2: Type: text/html, Size: 1002 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

below...

On Mon, Jul 6, 2020 at 3:36 PM John Cowan <cowan@ccil.org> wrote:

>
> On Mon, Jul 6, 2020 at 3:19 PM <arnold@skeeve.com> wrote:
>
> Huh? I've never seen this, in over 20 years of using vim. To
>> insert a newline just use
>>
>>         s/foobar/foo^V^Mbar/
>>
>> where ^V^M are Control-V Control-M.
>>
>
> I never thought of that; I've always tried what works in ed, namely:
>
> s/foobar/foo\
> bar
>
need a closing / for ed, but ex/vi accepts the naked version.




>
> and that gives me
>
> foo^@bar
>
> I call that a bug.  (This is vim 8.1).
>
In fairness, early vi did this too.  nvi (Bostic's rewrite) which came out
around 4.3 or 4.4 fixed it.



>
> It certainly wouldn't occur to me to use ^V^M, anyhow:  ^V^J would seem
> more reasonable, but ^V is ignored in that context.
>
I agree, I have tried to us the ^V^J idiom with different success.  Since
vim has been forced down my throat, I tend to not try it, and as you say,
switch editors when I need to add a newline.

>
> Before vim 7 there was a bug so bad I had to use nvi (and, often enough,
> compile it from source): at that time, undo undid everything back to the
> last action in vi-mode.  If you had never been in vi-mode (as I usually had
> not) it undid everything back to the last file-loading command!  That one
> made me grind my teeth a lot.  Even now I habitually write before undoing,
> just in case.
>
Amen ...   vim's undo can be ...  a ... challenging for original vi user -
but that has been debated here a few times and I'd rather not see another
war.
Clem

[-- Attachment #2: Type: text/html, Size: 3597 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[arnold]

Clem Cole <clemc@ccc.com> wrote:

> > It certainly wouldn't occur to me to use ^V^M, anyhow:  ^V^J would seem
> > more reasonable, but ^V is ignored in that context.
>
> I agree, I have tried to us the ^V^J idiom with different success.  Since
> vim has been forced down my throat, I tend to not try it, and as you say,
> switch editors when I need to add a newline.

As I said, ^V^M has worked flawlessly for me for > 20 years.

Arnold

Re: [TUHS] v7 uucp debugging help requested

[Win Treese]

> On Jul 6, 2020, at 4:48 PM, Clem Cole <clemc@ccc.com> wrote:
> 
>> 
>> I never thought of that; I've always tried what works in ed, namely:
>> 
>> s/foobar/foo\
>> bar
> need a closing / for ed, but ex/vi accepts the naked version.

In the mid 1980s, when I was working at MIT’s Project Athena,
one day Jerry Saltzer (MIT CS professor, known for work on CTSS
and Multics, among other things, and Technical Director for Athena)
called me into his office. 

He was trying to edit a file with ed on his IBM PC/RT workstation,
which was running IBM’s variant of 4.2BSD on it, and he wanted
to know why his search

	/foo

wasn’t working.

I typed /foo/, and everything was fine.

He looked at it and muttered, “Oh, you have to end it with a slash?
When I wrote this for CTSS, you didn’t need to do that.”

 - Win

Re: [TUHS] v7 uucp debugging help requested

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]

On Thu, Jul 9, 2020, 11:13 PM Win Treese <treese@acm.org> wrote:

>
> > On Jul 6, 2020, at 4:48 PM, Clem Cole <clemc@ccc.com> wrote:
> >
> >>
> >> I never thought of that; I've always tried what works in ed, namely:
> >>
> >> s/foobar/foo\
> >> bar
> > need a closing / for ed, but ex/vi accepts the naked version.
>
> In the mid 1980s, when I was working at MIT’s Project Athena,
> one day Jerry Saltzer (MIT CS professor, known for work on CTSS
> and Multics, among other things, and Technical Director for Athena)
> called me into his office.
>
> He was trying to edit a file with ed on his IBM PC/RT workstation,
> which was running IBM’s variant of 4.2BSD on it, and he wanted
> to know why his search
>
>         /foo
>
> wasn’t working.
>
> I typed /foo/, and everything was fine.
>
> He looked at it and muttered, “Oh, you have to end it with a slash?
> When I wrote this for CTSS, you didn’t need to do that.”
>

Kids today.... get off my damn regex...  even turning couldn't complete
this lot. Bah

:)

Warner


>
>
>

[-- Attachment #2: Type: text/html, Size: 1873 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Dave Horsfall]

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

On Thu, 9 Jul 2020, Warner Losh wrote:

>       He looked at it and muttered, “Oh, you have to end it with a
>       slash?
>       When I wrote this for CTSS, you didn’t need to do that.”
> 
> 
> Kids today.... get off my damn regex...  even turning couldn't complete this
> lot. Bah

I can see that a lot of people havent used CDC gear :-)

s:/old//new/

-- Dave

Re: [TUHS] v7 uucp debugging help requested

[Dave Horsfall]

On Mon, 6 Jul 2020, arnold@skeeve.com wrote:

> Huh? I've never seen this, in over 20 years of using vim. To insert a 
> newline just use
>
> 	s/foobar/foo^V^Mbar/

I'm surprised that not more people know about the ^V "escape next 
character" trick.

-- Dave

Re: [TUHS] v7 uucp debugging help requested

[arnold]

Dave Horsfall <dave@horsfall.org> wrote:

> On Mon, 6 Jul 2020, arnold@skeeve.com wrote:
>
> > Huh? I've never seen this, in over 20 years of using vim. To insert a 
> > newline just use
> >
> > 	s/foobar/foo^V^Mbar/
>
> I'm surprised that not more people know about the ^V "escape next 
> character" trick.
>
> -- Dave

It's described quite clearly in O'Reilly's book on vi and vim (coauthored
by yours truly - plug, plug :-).

Arnold

Re: [TUHS] v7 uucp debugging help requested

[Dave Horsfall]

On Tue, 7 Jul 2020, arnold@skeeve.com wrote:

>> I'm surprised that not more people know about the ^V "escape next 
>> character" trick.
>
> It's described quite clearly in O'Reilly's book on vi and vim 
> (coauthored by yours truly - plug, plug :-).

Never read the book, since I'd already known VI by then :-)  I'm not sure 
where I picked it up; possibly from the manpage?  But we know the saying 
about programmers not reading documentation...

-- Dave

Re: [TUHS] v7 uucp debugging help requested

[Dave Horsfall]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On Mon, 6 Jul 2020, Clem Cole wrote:

> I always recommend doing the exercises in Rob and Brian's UPE on ed 
> because then everything else makes sense, like sed or any other editor.  
>  Plus you get the advantage you point out, and the reality is that so 
> many simpler editors (like edlin) have similar functionality, it means 
> you can get something done, just about anywhere.

There was also the client we had in PNG, where access was via a flakey 
1200 modem i.e. no error correction, and VI was out of the question.

I learned to use ED when V5 first appeared (down-under) in the 70s (it was 
the *only* editor) and I'm glad that I did.

I must grab a copy of UPE and read it again, just for old times' sake.

-- Dave

Re: [TUHS] v7 uucp debugging help requested

[John Cowan]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Mon, Jul 6, 2020 at 5:19 PM Dave Horsfall <dave@horsfall.org> wrote:


> There was also the client we had in PNG, where access was via a flakey
> 1200 modem i.e. no error correction, and VI was out of the question.
>

The old 'o' command (which does the same as 'vi' in vim) was designed for
that situation, provided your terminal isn't a printing one.  A one-line
window is cheap enough; backspace and carriage-return give you
everything you need.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
The Imperials are decadent, 300 pound free-range chickens (except they have
teeth, arms instead of wings, and dinosaurlike tails).  --Elyse Grasso

[-- Attachment #2: Type: text/html, Size: 1201 bytes --]

[TUHS] Editors (was: v7 uucp debugging help requested)

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On Monday,  6 July 2020 at  9:57:49 -0400, Clem Cole wrote:
> I always recommend doing the exercises in Rob and Brian's UPE on ed
> because then everything else makes sense, like sed or any other
> editor...

People (not just Clem), when you change the topic, can you please
modify the Subject: to match?  I'm not overly interested in uucp, but
editors are a completely different matter.  I'm sure I'm not the only
one, so many interested parties will miss these replies.

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Norman Wilson]

Grant Taylor:

  I'm a little surprised that you're trying to use the 'g' protocol to 
  talk to v7.  I thought the 'g' protocol came out later for TCP over 
  Ethernet connections.  As such I wonder if UUCP on v7 supports the 'g' 
  protocol.

=====

You're mis-remembering.  g was the original protocol,
intended for use over possibly-noisy serial lines (e.g.
modems on POTS).  It does error checking of various
sorts with retransmission.  I believe it is named g
after the protocol's original designer, Greg Chesson.

Later protocols meant to work over reliable, error-
checked links like a TCP/IP circuit were t and e.

Norman Wilson
Toronto ON

Re: [TUHS] v7 uucp debugging help requested

[Norman Wilson]

Dave Horsfall:

  A boss of mine insisted that we all learned "ed", because one day it might 
  be the only editor available to you after a crash; he was right...

====

Besides which, as The Blessed Manual said in every
Research edition:
	ed is the standard text editor.

Norman Wilson
Toronto ON
(typing this in Toronto qed)

Re: [TUHS] v7 uucp debugging help requested

[Rob Pike]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

The thing about ed that is missed by johnny-come-latelys who mock it for
its lowness is that it was so much higher than most, if not all the
commercially available text editors of its time. The gold standard was
perhaps Son of Stopgap, whose very name tells you the state of things.

I remember spending a couple of days baking inside a radio telescope
control cabin implementing a miniature version of ed in forth just so I
work more effectively on the task to come.

-rob


On Wed, Jul 8, 2020 at 5:22 AM Norman Wilson <norman@oclsc.org> wrote:

> Dave Horsfall:
>
>   A boss of mine insisted that we all learned "ed", because one day it
> might
>   be the only editor available to you after a crash; he was right...
>
> ====
>
> Besides which, as The Blessed Manual said in every
> Research edition:
>         ed is the standard text editor.
>
> Norman Wilson
> Toronto ON
> (typing this in Toronto qed)
>

[-- Attachment #2: Type: text/html, Size: 1306 bytes --]

Re: [TUHS] v7 uucp debugging help requested

[Adam Thornton]

> On Jul 7, 2020, at 3:47 PM, Rob Pike <robpike@gmail.com> wrote:
> 
> The thing about ed that is missed by johnny-come-latelys who mock it for its lowness is that it was so much higher than most, if not all the commercially available text editors of its time. The gold standard was perhaps Son of Stopgap, whose very name tells you the state of things.
> 
> I remember spending a couple of days baking inside a radio telescope control cabin implementing a miniature version of ed in forth just so I work more effectively on the task to come.

As the person who kicked off this last round of editor wars by saying I wanted “s” on my v7 system to make it into a daily driver: sure, ed’s not terrible.  I can, and have, used it, although in most places where I *would* use it, I also have sed available, and using sed and then comparing the output and the input is just as fast for me and carries less risk of hosing my input file.

As line editors go it’s just fine and indeed rather easier than TECO or EDLIN, which are the other two I’ve used from time to time.  Oh.  And CMS EDIT which it is about on a par with.

But I still find it much less pleasant to use than a moderately-OK screen editor, which “s” certainly is.  Largely that’s because I don’t think before I type anymore, and I hit keys fast and sometimes inaccurately, because the last 35 years have taught me that I can always go back and fix it up.

Now that I have working editing-for-the-sloppy and a way that I can reliably transfer files to and from v7, really all I need to do is mess with the terminal driver so that ^? isn’t immediately-cancel-line, because that too is a finger habit too hard for me to break.

Adam