> From: Clem Cole <clemc(a)ccc.com>
> another old V6 trick is the use file redirection from the different
> terminal to unlock a hosed tty.
'stty {mumble} > /dev/ttyX', in case that wasn't clear.
Note that this only works if you have a working shell on _another_ terminal,
so if you're e.g. working with an emulation which has only one working
terminal, and your raw-mode program on it has gone berserk, 'See Figure 1'.
It really is advised to have another working terminal if you want to play
with raw-mode programs.
Noel
I got a diff for adding actual backspace and delete to v7, linked off of
gunkies... Anyhow, I can manually edit the referenced files and rebuild,
but I would rather do it canonically. I don't see patch anywhere, so did
v7 users use diffs to patch source and if so what's the magic?
Thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
Echoing other answers, I regularly use groff in Cygwin.
If you're into Unix/Linux, Cygwin is a great tool with a
remarkably clean installation process. I use default
PostScript output by choice, because I can tinker with
PostScript but not with PDF. ps2pdf (available from
Cygwin) has always worked when I need PDF.
I must admit, tough, that this approach will be pretty
onerous if you do not want Cygwin for any other
reason. And I should add that PoscScript requires a
special viewer; I use gsview.
Doug
As y'all know, I'm a relative latecomer to the world of Unix, but I do
try to figure out how y'all did it back when. So, sometimes, as in this
case, I can figure out how to do something, but I'm curious how it was
done back in the day, moreso than how I can get it done today. I'm
looking at the patching of my shiny new 2.11 BSD pl 431 system running
on my speedy little virtual PDP-11/70, so I grabbed patch 432 (here's a
portion of the patch):
...
To install the update cut where indicated below and save to a file
(/tmp/432) and then:
cd /tmp
sh 432
./432.sh
./432.rm
sh 432.shar
patch -p0 < 432.patch
Watch carefully for any rejected parts of the patch. Failure of a
patch typically means the system was not current on all preceeding
updates _or_ that local modifications have been made.
...
====== cut here
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create:
# 432.rm
# 432.sh
# 432.shar
# 432.patch
...
# End of shell archive
This seems straightforward. Just follow the directions et voila magic
happens.
My questions for y'all are how would you go about doing this? Use vi to
delete everything through the ==== cut here line? Use some combination
of standard unix tools to chop it up? What was your workflow for
patching up the system using these files?
In my world, if I screw something up, it's 15 seconds to run a restore
script in my simh directory and I can try again, so my level of concern
for a mistake is pretty low. If I was doing this in 1980, on real
hardware, I would have had many concerns, as I'm sure some of y'all can
remember, how did you prepare and protect yourselves so a patch was
successful.
BTW, I thought .shar was an archive format, so when I saw the patch was
a shar file, I was worried it would be in some binary form, lo and
behold, it looks like text to me... not even b64. So much to learn, so
little time.
Thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
> From: Larry McVoy
> Yeah, write is unbuffered though I think Noel is correct, it's going to
> a tty and the tty will buffer until \n
The 'wait until newline' is on the input side.
Output is buffered (in the sense that characters are held in the kernel until
the output device can take them); but normally output will start to happen as
soon as the device is able to take them. Only a certain amount can be
buffered though, after that (the 'high water', I think it's called), the
process is blocked if it tries to do output, and awakened when the buffered
output level goes past the 'low water' mark.
Note that getchar() and putchar() are subroutines in a library; looking
at the source:
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s4/getchr.s
you can see how they relate to the actual read/write calls to the OS.
> So you probably have to set the tty in raw mode
Probably best to run such programs from something other than the main console,
because if there's a bug in the program, and the terminal is in raw mode, if
you're on the console, you may have to reboot the system to regain control of
the system. (Interrupt characters, ^D etc won't work.)
> (sorry that I'm vague, I never ran V6).
Tnat's OK, I pretty much have the V6 kernel memorized, from working with
it back in the day... :-)
Noel
I am using C in V6 to create a Forth compiler. I don;t have any interest in
Forth as a general purpose language, however I do like it. It's satisfying
to create a language from the ground up. I'm interested in it a simple and
extensible interpreted language for toying with my PDP-11s, so I'll have
some with it in the future.
I have a very basic problem. I am simply using getchar and putchar for
console IO, which is convenient indeed. I'm struggling however with how C
processes the IO. It seems that when I type at the console, my typing is
immediately echoed to my terminal window. When I press backspace the system
responds with the character that was deleted, which is fine, as I assume it
was from the paper teletype days. However, my code is receiving input and
also echoing the output, but nothing appears on the terminal until I press
enter, when the system displays the whole line of input, which is
essentially a duplicate of what the terminal originally displayed, but with
the consolidated edits. My code is reading and echoing the input character
by character.
Here's my question. How can I suppress the original C/Unix echo, and get my
output to appear immediately? This simple sample code form the C
programming manual behaves the same.
int main() {
int c;
while ((c = getchar()) != EOF) {
putchar(c);
}
}
Paul
*Paul Riley*
Mo: +86 186 8227 8332
Email: paul(a)rileyriot.com
I'm hearing that 50% of what's left of AT&T research got the axe today.
I'm hoping to hear from friends about details.
God's gift to google, as we have said in the past.
Henry Bent:
Are there any former Bell Labs sysadmins on this list? My father was the
sysadmin for hoh* (Crawford Hill, mostly the radio astronomy folks) in the
mid-late '80s and early '90s and I would be especially interested to hear
from hou* (Holmdel, what a building!) folks but also ihn* (Indian Hill) and
the like. I'm very curious about what life was like on the ground, so to
speak.
=====
It is worth pointing out that, like many universities, Bell
Labs had at least two layers of computing and therefore of
sysadmins. There were official central Comp Centers, which
is the world Henry asks specifically about; but there were
also less-central computing facilities at the divisional and
center and department level.
I never worked for a comp center, but my role in 1127 was
basically that of sysadmin for our center's own systems;
the ones used both for our day-to-day computing (including
that known to the uucp world as research!) and for OS and
other experiments and research and hacking.
There were also two large VAXes called alice and rabbit,
which afforded general-use computing for other departments
in Division 112. Us 1127 sysadmins (I wasn't the only one
by any means) ran those too; I don't know the full history
but I gather that happened because there was some desire
to run the Research version of UNIX rather than the comp-center
one for that purpose.
One system I had hands in straddled the researcher/comp-center
boundary: 3k, the Cray X-MP/24 bought specifically for
researchers. It was physically located in the comp center,
but managed jointly: it ran Cray's UNICOS but with
substantial additions from the Research world, including
the stream I/O system (which is rather self-contained so
it was not too hard to graft into a different UNIX) and
Datakit support (using a custom interface board designed
and built by Alan Kaplan and debugged by me and Alan
over several late-night sessions. (I remember that
the string "feefoefum\n", which is an obscure cultural
reference from one of my previous workplaces, was
particularly effective at shaking out bugs!)
Once UNICOS-a-la-Research was running stably, staff from
the Murray Hill Comp Center looked after day-to-day
operations, with Research involved more for software
support as needed.
Norman Wilson
Toronto ON
Are there any former Bell Labs sysadmins on this list? My father was the
sysadmin for hoh* (Crawford Hill, mostly the radio astronomy folks) in the
mid-late '80s and early '90s and I would be especially interested to hear
from hou* (Holmdel, what a building!) folks but also ihn* (Indian Hill) and
the like. I'm very curious about what life was like on the ground, so to
speak.
I'll start off with a quick anecdote. When I started college I began
working for the computing center doing menial jobs. There was an older,
ex-army guy leading the networking department who extolled the virtues of
the VAX up and down; I think Oberlin would have kept the VAX 6620 running
VMS 5.5 forever if he had his way. Anyway, I mentioned his position to my
father and he told me that the best thing he ever did was replace the VAX
systems (and the endless mounting/remounting of RL02s for user data) with
early generation Sun 4 systems.
-Henry
Coming upon this dedication in W.B. Yeats's book, "Irish Folk
stories and Fairy Tales", I felt a frisson of connection: "Inscribed
to my mystical friend, G. R." Mystically present in the Unix room
and on the 1127 org chart, G. R. Emlin took a place in our little
community akin to that of fairies in Irish peasant culture. First
encountered by Fred Grampp, G. R. manifested to others in various
guises, ranging from Grace Emlin, whom I remember as a security guru,
to a Labs-badged apparition now housed in the corporate archives
(www.peteradamsphoto.com/unix-folklore/) My most memorable personal
encounter was when I received from G. R. a receipt for paint for the
water-tower project (spinrooot.com/pico/pjw.html) as part of a request
for reimbursement. I passed the voucher up the chain of command to
our executive director, Vic Vyssotsky. Unfortunately for G. R., Vic,
despite his masterful ability to bypass bureaucratic obstacles,
declared he wasn't authorized to approve plant improvements.
Doug
Hi All,
I'm currently doing some work with 211BSD and the best version that I've
come across for my investigations is the one put together by Andre
Luvisi, based on the distro in the Unix Archive at
https://tuhs.v6shell.org/UnixArchiveMirror/Distributions/UCB/2.11BSD
So far as I can figure out (and I'm a little bit fuzzy around the
edges), this appears to be patch level 431, at least according to
https://tuhs.v6shell.org/UnixArchiveMirror/Distributions/UCB/2.11BSD/VERSION.
I have a number of questions that hopefully, someone can shed some light on:
1. Is it really pl 431?
2. How can I tell?
3. Is it the latest tape image available (I've seen plenty of disk
images, but those are already installed)?
4. Is there a howto bring it up to the next patch level document lying
around somewhere?
I've seen Warner's work on going the other direction and that's
fascinating in it's own right, but I'd like to see about patching up to
latest.
Thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
Well, I figured out number 4, duh!
4. Is there a howto bring it up to the next patch level document lying
around somewhere?
Each patch is self documenting :). Just do what it says and it should
work... we'll see!
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
On 7/19/20, emanuel stiebler <emu(a)e-bbes.com> wrote:
>
> That's why DEC made also the MicroVAX. I had once a MVII/BA23 in my
> samsonite. Weird look at customs, but worked ;-)
>
By the early 1980s it was apparent that some of the more complicated
VAX instructions weren't worth the space they took up in firmware.
Especially POLY and EMOD, which turned out to be both slower and less
accurate than coding them up as subroutines. And the PL/I and COBOL
compilers were implementing packed decimal using decimal shadowing.
Chucking out those instructions and doing them by emulation in the OS
freed up enough chip real estate to allow the remaining VAX
architecture to be implemented on a chip. All the later VAXen
supported only the MicroVAX subset architecture in hardware/firmware.
I don't recall which was the last VAX to support the whole
architecture in hardware/firmware. Perhaps the VAX 8200/8300
(Scorpio)? That was a single-board implementation. It could be
paired with a high-end Evans & Sutherland 3D graphics monitor. DEC
tried unsuccessfully to use that combination to compete with Apollo in
the workstation market, but it was too little too late. One reviewer
said that coupling the E&S graphics to the VAX 8200 was like
turbocharging a lawn mower. Did Unix support that configuration, or
was it VMS-only?
-Paul W.
IMMSMC the early Linux had problems with some old-good programs i.e. Sendmail.
New-born Linux hesitated between POSIX-BSD-Solaris semantic
i.e. in file-locking, pty, network interface binding e.t.c.
>From the early Sendmail README:
===
Linux
Something broke between versions 0.99.13 and 0.99.14 of Linux:
the flock() system call gives errors. If you are running .14,
you must not use flock. You can do this with -DHASFLOCK=0.
Around the inclusion of bind-4.9.3 & linux libc-4.6.20, the
initialization of the _res structure changed. If /etc/hosts.conf
was configured as "hosts, bind" the resolver code could return
"Name server failure" errors. This is supposedly fixed in
later versions of libc (>= 4.6.29?), and later versions of
sendmail (> 8.6.10) try to work around the problem.
Some older versions (< 4.6.20?) of the libc/include files conflict
with sendmail's version of cdefs.h. Deleting sendmail's version
on those systems should be non-harmful, and new versions don't care.
Sendmail assumes that libc has snprintf, which has been true since
libc 4.7.0. If you are running an older version, you will need to
use -DHASSNPRINTF=0 in the Makefile. If may be able to use -lbsd
(which includes snprintf) instead of turning this off on versions
of libc between 4.4.4 and 4.7.0 (snprintf improves security, so
you want to use this if at all possible).
NOTE ON LINUX & BIND: By default, the Makefiles for linux include
header files in /usr/local/include and libraries in /usr/local/lib.
If you've installed BIND on your system, the header files typically
end up in the search path and you need to add "-lresolv" to the
LIBS line in your Makefile. Really old versions may need to include
"-l44bsd" as well (particularly if the link phase complains about
missing strcasecmp, strncasecmp or strpbrk). Complaints about an
undefined reference to `__dn_skipname' in domain.o are a sure sign
that you need to add -lresolv to LIBS. Newer versions of linux
are basically threaded BIND, so you may or may not see complaints
if you accidentally mix BIND headers/libraries with virginal libc.
If you have BIND headers in /usr/local/include (resolv.h, etc)
you *should* be adding -lresolv to LIBS. Data structures may change
and you'd be asking for a core dump.
I've managed to reach an important milestone in my efforts to recreate
2.11BSD pl 0 from sources. I've managed to unwind the patches, recreated
some programs that were lost (the patches destroyed data and weren't modern
context diffs).
So I've managed to unwind back to pl 0, I've managed to bootstrap the
assembler (it wouldn't build on pl 195), recreate ld, ranlib and ar. I've
rebuilt the libraries and many binaries.
https://bsdimp.blogspot.com/2020/07/211bsd-original-tapes-recreation.html
No tapes yet, but I thought people here would like to know.
Warner
(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%20Insta…
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
John Linderman:
Every "divestiture" had an adverse effect on critical mass. The split
between AT&T and Bellcore was a big hurt.
The split between AT&T and Lucent was another. When I joined the Labs in
1973, it was an honor to work there.
====
Maybe I'm blinded because I wasn't there earlier, but
to me, joining Bell Labs in 1984, just after the original
divestiture that split off Bellcore, was still an honour.
There were certainly good people I never had a chance to
work with because they went to Bellcore, but in 1127 at
least, morale was good, management stayed out of our way
and encouraged researchers to work on whatever interested
them, and a lot of good work was done even if that group
was no longer the source of All UNIX Truth. (In fact I
think we missed the boat on some things by being too
inwardly-focussed, TCP/IP in particular, but divestiture
didn't cause that.)
It seemed to me that the rot didn't really begin to show
until around 1990, the time I left (though not for that
reason; this is hindsight). Upper management were
visibly shifting focus from encouraging researchers to
do what they did best to treating researchers as a source
of new products to be marketed. The urge to break the
company up further seems to me to have been a symptom,
not a cause; the cause was a general corporate shift
toward short-term profits rather than AT&T's traditional
long-term view. AT&T was far from alone in making this
mistake, and research in the US has suffered greatly all
over as a result.
I remember visiting a couple of years after I left, and
chatting with my former department head. He said 1127
was having trouble convincing new researchers to join up
because they'd heard (correctly) that the physics and
chemistry research groups were being cut back, and feared
computing science would have its own reckoning soon enough.
In fact the corporate direction of the time was to cut
back on the physical sciences and push to expand software
research and development, but I don't blame the new
researchers for being concerned (nor did my ex-DH), and
in the long term they turned out to be more right than
wrong.
Nothing lasts forever, but the classic Bell Labs lasted
a long time. We have nothing like it now. I don't think
we'll have anything like it any time soon. That's sad.
Norman Wilson
Toronto ON
Preferring fewer emails, but not wanting to miss out on topics
that had not occurred to me, I would continue to subscribe
to the digest and not switch to a topic-filtering option.
Doug
On 7/6/20 7:30 PM, Greg 'groggy' Lehey wrote:
> 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.
I see this type of change happen — in my not so humble opinion — /way/
/too/ /often/.
So, I'm wondering if people are interested in configuring TUHS and / or
COFF mailing list (Mailman) with topics. That way people could
subscribe to the topics that they are interested in and not receive
copies of topics they aren't interested in.
I'm assuming that TUHS and COFF are still on Mailman mailing lists and
that Warren would be amicable to such.
To clarify, it would still be the same mailing list(s) as they exist
today. They would just have the to be utilized option of picking
interesting topics. Where topics would be based on keywords in the
message body.
I'm just trying to gauge people's interest in this idea.
--
Grant. . . .
unix || die
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)
John Cowan:
Very much +1. Part of the trouble is that Gmail and similar clients don't
routinely show you the Subject: line to make it easy to edit it; you have
to take affirmative action when you want to change the subject matter.
====
Perhaps we should take a leaf from 1980s Rob Pike, and
just automatically change every message to be
Subject: The content of this message
(There is an actual story behind that, but I'll leave it
to Rob to tell.)
Norman Wilson
Toronto ON
