I'm trying to get 2bsd.tar extracted into v7. Does anyone have any
recollection how to do this. Here's what I'm seeing:
in simh:
simh> att tm0 -V -F TAR 2bsd.tar
Tape Image '2bsd.tar' scanned as TAR format.
contains 4935680 bytes of tape data (482 records, 1 tapemarks)
c
and in v7:
tar xv0
tar: bin/ - cannot create
directory checksum error
# ls
bin
What gives - it says it can't create the dir, but it does, it's there...
Thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
> There was quite some communication between Peter Nilson (npn, known
> for picasso) and bwk.
In the interest of accuracy npn's full name is Nils-Peter Nelson.
He honchoed the Bell Labs Cray and originated <string.h>.
Doug
Hi folks,
I used thack to typeset my dissertation on v7 circa 1988. It converts C/A/T codes to postscript. i have no idea if it will cope with eqn or pic but it was enough for nicely formatted text as i remember.
this is the patch/bugfix with a link to the original package.
https://www.tuhs.org/Usenet/comp.sources.misc/1989-July/001073.html
-Steve
Nemu Nusquam:
When was dpost born?
=====
CSTR 97, A Typesetter-Independent TROFF by Brian W Kernighan
was issued in 1981 and revised the next year. So that's the
earliest possible date.
I vaguely remember the existence of Postscript support in
general, including at least one Apple Laserwriter kicking
around somewhere, starting at some point during my time at
1127 in the latter 1980s. There was even a Postscript
display engine that ran on 5620 terminals under mux, though
it wasn't normally used for troff previewing because the
troff-specific proofer was faster (mainly, I think, it
didn't send nearly as much data down the serial line to
the terminal).
My personal snapshot of V10, and the TUHS archive copy,
include dpost; see src/cmd/postscript/dpost. Everything
in the postscript directory came from USG, who had
packaged everything troff into a separately-licensed
Documenter's Workbench package. That may have made us
exclude it from the officially-distributed V8 tape and
V9 snapshots. In any case, the only V9 snapshot I know
of offhand (which is in Warren's archive) has no dpost.
Both my copy of V10 and the TUHS copy show dpost's
source files with dates in 1991, but it was certainly
there earlier if I used it in New Jersey (I left in
mid-1990). Dpost is documented in man8/postscript.8;
my copy of that file is dated October 1989.
Digging around in documents available on the web,
I found a bundle of DWB 2.0 docs:
http://www.bitsavers.org/pdf/att/unix/Documentors_Workbench_1989/UNIX_Syste…
It's a scanned-image PDF so I can't search it by
machine, but it includes such things as listings of
the source-code directory and manifests of various
binary distributions, and dpost doesn't appear anywhere
I can see. As the URL implies, the docs seem to
be dated 1989. So maybe dpost wasn't part of the
product until DWB 3.0; but maybe we in Research got
an early copy of the postscript stuff (I think bwk
was in regular communication with the USG-troff
folks), perhaps in 1989.
I confess I've lost track of the original question
that spawned this thread, but if it is whether
dpost is easily back-ported to PDP-11 UNIX, I don't
think that's likely without a good bit of work.
It would very likely require a post-1980-type C
compiler, since it was written in the late 1980s.
It might or might not fit on a PDP-11; I don't
remember whether USG's system still officially
ran there by the late 1980s.
Norman Wilson
Toronto ON
> From: Paul Riley
> 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. ... nothing appears on the terminal until I press enter, when
> the system displays the whole line of input ... How
> can I suppress the original C/Unix echo, and get my output to appear
> immediately?
This is not a C issue; it's the Unix I/O system (and specifically, terminal I/O).
Normally, Unix terminal input is done line-at-a-time: i.e. the read() call to
the OS (whether for 1 character, or a large number) doesn't return until an
enire line has been typed, and [Retrurn] has been hit; then the entire line is
available. While it's being buffered by the OS, echoing is done, and rubout
processing is also performed.
One can suppress all this; there's a mode call 'raw' (the normal mode is
sometime labelled 'cooked') which suppresses all that, and just gives one the
characters actually typed, as they are typed. The stty() system call can be
used to turn this on.
See the V6 tty(IV) manual entry for more. stty() is in stty(II).
Noel
> 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
