There may be a simple generic way to correct pic's habit of accepting
any set of object modifiers on any object, but obeying only a
compatible subset.
Pic already collects a bit vector of modifier types attached to the
current object. If that were extended with a few more bits that
designate the object types, the size, B, of the bit vector would be
about 35--an easy fit in one 64-bit word. Then a BxB bit matrix could
record both modifier/modifier incompatibilities and object/modifier
incompatibilities. The collected bit vector needs to be tested against
the matrix once per object definition.
It seems to be harder to catch duplication of modifiers, requiring
extra code at all points where bits are set. Nevertheless, this kind
of error also merits detection.
Some questions
Does anybody think the issue is not worth addressing?
Is there a better scheme than that suggested above?
Is the scheme adequate? It would not, for example, catch a three-way
incompatibility that does not entail any pairwise incompatibility,
should such an incompatibility exist.
Any other thoughts?
Doug
Good day, I've just received in the mail a UNIX System User Reference Manual for the 3B5 computer. It has a few differences with other documentation around it. As usual with an initial expository message, lots of info here, mostly so it'll get in the archive and on the record.
So first off, I can't find a version reference in this thing. It is branded as "UNIX System" consistent with the branding nomenclature in the System V era, but I can't actually find the term "System V" anywhere thus far. However, a high level view implies relative parity with the initial release of System V. There are some areas where nomenclature is closer in character to the Release 5.0 manual, for instance, the "basinf" section in the intro refers to the user guide as "UNIX User Guide" rather than "UNIX System User's Guide" which is found in later System V stuff. In fact, this minor reference may point to some branching in the documentation between 4.x and SVR2 as I have the following in various manuals (prior to 4.1 i.e. 3.0/SysIII the reference is still directly to UNIX For Beginners, not a guide):
- Release 4.1 - "UNIX User's Guide"
- Release 5.0 - "UNIX User's Guide"
- Release 5.0 BTL - "UNIX User's Guide"
- System V - "UNIX System User's Guide"
- System V 3B5 - "UNIX User Guide"
- System V R2 BTL - "UNIX System User Guide"
- System V DEC (1984) - "UNIX System User Guide"
- System V R2 (1986 Manuals) - "UNIX System User's Guide"
So SysV adds "System" to what was in Release 5.0, this carries through to conventional SVR2. The 3B5 version, however, drops the apostrophe and 's' that were in the pre-SysV nomenclature but doesn't add "System". Then even more confusing the SVR2 BTL copy appears to bear some lineage from this as it also has the dropped apostrophe and 's' but includes "System". Strange. Even stranger is I decided to take a peek at SVR2 docs from 1984, they lack the apostrophe and 's', but later SVR2 material from 1986 restores it. I wonder if this implies the 3B5 branch was started in the 5.0 days, diverged a bit, and then was only partially recombined with System V before release, although on the flip side, this manual *does* include the edit, ex, and vi manpages which were not printed in time for the System V manual run (as they are included with a separate documentation package instead.) This tracks with the BTL 5.0 having edit, ex, vi, and termcap present from Holmdel, the BTL manual got the pages early. All that to say, there are things in this manual that aren't yet in published System V manuals at the time, but there are things in this manual that have since been altered by the time of the formal System V documentation, pointing to an earlier branch point and then ongoing cross-talk after that.
Included are references to a "3B Computer Network" and a few utilities associated. There are a few other pages too I didn't see in other contemporary public manuals, in total:
- dcon(1) - Spawns a shell on a remote system via a DATAKIT circuit
- logdir(1) - Returns the home directory field from /etc/passwd, this is in the BTL versions, I don't see it in public SysV though
- ncp(1) - Copies files over the DATAKIT network
- nisend(1) - Copies files over the "3B Computer Local Network"
- nistat(1) - Query the status of said network
- nitable(1) - Display the configuration table of said network
- niupdate(1) - Update said configuration table
- nkill(1) - Kill but using process names instead of IDs, but doesn't define process names, be it argv[0], the name of the image file, etc...
- rexec(1) - Executes commands over a DATAKIT network
- rl(1) - Login remotely over the 3B Computer Network (distinct from dcon being DATAKIT remote logins) This appears to be uucp-derived (specifically cu(1))
- dkdial(3) - Dials a DATAKIT connection
- boothdr(4) - 3B5 only, provides the contents of <sys/boothdr.h> which supports storing parts of master(4), via mkboot(1M), in "a driver object file" to be used with "the self-config boot".
Section 6 is mentioned in the intro but then omitted from the rest of the manual, so nothing to compare there. Also keeping with the documentation changes at the time, this does not include Sections 1M, 7, nor 8, as those are presumably in an accompanying Administrator's Reference Manual. That is another thing pegging this as System V rather than SVR2, by SVR2 they had further divided from two to three manuals, splitting the user manual into Sections 1 and 6 (User) and Sections 2, 3, 4, and 5 (Programmer) (although even this isn't entirely true, I've got a "UNIX User's Manual" published in 1986, red ATTIS-style cover, that contains what appear to be selections from Sections 1, 2, and 3...it seems more geared towards folks writing portable software between SVR1 and SVR2 than anything)
Finally, here are the omissions I compared with the SVR2 BTL, SVR2 DEC, and 1986 manual mentioned above:
Removed by SVR2 public, only in the BTL version:
- nscstat(1)
- nsctorje(1)
- nusend(1)
- stlogin(1)
- ststat(1)
Non-portable DEC stuff:
- adb(1)
- arcv(1)
- kasb(1)
- net(1)
- vpr(1)
- maus(2)
- x25alnk(3) - This X.25 stuff never shows back up, probably dropped as of SVR2 BTL (1983)
- x25clnk(3)
- x25hlnk(3)
- x25ipvc(3)
Non-portable 3B20S stuff:
- cprs(1)
- hpio(1)
Honeywell/GCOS Interop, gone by SVR2 BTL (1983):
- dpd(1)
- dpr(1)
- fget(1)
- fsend(1)
- gcat(1)
- gcosmail(1)
Graphics Subsystem, remains in SVR2 so probably not 3B5 supported as of this printing:
- gdev(1)
- ged(1)
- graphics(1)
- gutil(1)
- stat(1)
- toc(1)
So just to review, some matters this manual supports:
- The initial 3B5 UNIX release seems closest in character to the initial System V version
- Many DEC and 3B20-specific components are omitted
- The Honeywell/GCOS interop was on the way out the door and likely never ported
- The graphics subsystem was not supported on 3B5 as of this release
- Synchronous terminals and NSC networking are taken internal likely by this release, certainly by SVR2
- The 3B5 version supported "DATAKIT" and "3B Computer Network" networks
- Included a logdir(1) command used in BTL for getting a user's login directory from /etc/passwd
- Included an nkill(1) command to kill a process by its (undefined) name
- The boot process included a header object for "driver object files" used with a "self-config boot" process
If there are any questions or any pages folks think I should peruse for details, just let me know. Otherwise this'll won't be hitting my detailed analysis for a while, I'm currently in the midst of figuring out a branching scheme in my mandiff repo that'll facilitate tracking the various forks, as I've found many changes between V5 and V6 that are *not* reflected in various ways throughout PWB, Program Generic, CB, and 32V (as an example, go look up where lpr(I) is and isn't available.)
- Matt G.
P.S. Kudos to the production quality of this manual. It's a small binder, the pages are the same size as the earlier comb-bound manuals. The binder rings themselves are fixed to the back cover and the right side of the rings is flat instead of rounded, so the pages sit very nicely whether opened or closed. This compares with the BTL SVR2 binder where the rings are perfectly round and affixed to the spine instead, so they sit differently depending on whether the binder is on a shelf or open on a desk, with pages risking getting all crumpled up getting bunched up at the edge of the rings. Certainly has nothing to do with software or technical history, but the physical nature of the various publications has also been factoring into my study. Here's a picture of the two covers by the way, since I haven't given any visuals on my work in a while: https://i.imgur.com/hhaaxfA.jpeg
At 2023-06-17T05:19:46+1000, Damian McGuckin wrote:
> Getting back to groff, that final/terminating sigma, is it still
> pronounced as sigma.
>
> It certainly has no EQN equivalent name and its groff short symbol
> name is
>
> \(ts
>
> (terminal sigma) which is not like other greek letters. Just
> wondering whether it needs a sentence to mention its abscence from
> EQN.
There are a few others, but they postdate Ossanna troff. From
groff_char(7) in 1.23.0.rc4:
ϵ \[+e] u03F5 variant epsilon (lunate)
Ï‘ \[+h] u03D1 variant theta (cursive form)
Ï– \[+p] u03D6 variant pi (similar to omega)
φ \[+f] u03C6 variant phi (curly shape)
Ï‚ \[ts] u03C2 terminal lowercase sigma +
I know of no reason to make these generally available by default in eqn,
though, any more than they already are. You can type their special
characters in eqn input and assign spacing and style types to them.
(This typing system is a GNU eqn feature, not present in AT&T eqn).
In fact I have a coupled pair of reforms in mind for GNU eqn:
unfastening the definitions of the lowercase Greek special characters
from the typeface used for letters (variables), and then defining the
lowercase Greek letter eqn macro names ("alpha", "beta", ...) to
explicitly use the "letter" style type.
https://savannah.gnu.org/bugs/?64232https://savannah.gnu.org/bugs/?64231
(For example:
define alpha ! type "letter" \(*a !
)
This should result in no change for historical documents (except on
terminals, where it will fix a bug), and give us some flexibility for
users of modern fonts where Greek letters are properly supported in text
fonts (i.e., in four styles).
The Graphic Systems C/A/T had uppercase Greek available _only_ upright
and lowercase Greek _only_ italic. Modern typesetting systems are not
so limited.
Regards,
Branden
At 2023-06-16T14:22:22+1000, Damian McGuckin wrote:
> On Thu, 15 Jun 2023, G. Branden Robinson wrote:
> > But I may suffer from an excessive familiarity with this material.
>
> Yes. Me too. Maybe that is a sad comment on the both of us.
That is the price of trying to leave things better than one found them.
> Why do Greeks have an alternate way of writing sigma!
We English-speakers used to have an alternative way of writing it, if
you regard the Latin alphabet's "S" as cognate (so to speak) with the
Greek sigma (and I think doing so is defensible). It's even in Unicode
with a low code point, U+017F.
For inſtance, the United States uſed to employ a non-final lowercaſe S
in the founding documents of its preſent government, where you can see
exhibits of the "Congreſs of the United States".
It can take the modern reader a "long S" time to not read that "s" as an
"f".
And if you think that's difficult enough, check out, IIRC, the Arabic
and Devanagari scripts where you can have different initial, medial, and
final forms for letters.
Follow-ups ſhould probably be confined to groff@; I'll ſtop now leſt we
get ſent to the COFF liſt for groſs tranſgreſſions of topicality.
(Although if anyone wants to tell me whether non-final s was applied to
the trailing ends of non-final morphemes _within_ words, I'm all ears.)
Regards,
Branden
I am not convinced that using special characters rather than in-line
eqn is a good thing. It means learning a whole new vocabulary. Quick,
what's the special character for Greek psi?
I have found that, for a sequence of displayed equations as in an
algebraic derivation, a pile often looks more coherent than a sequence
of EQ-EN pairs. The pile can even contain interleaved comments, as in
Hoare-style proofs.
Doug
On Tue, Jun 13, 2023 at 9:29 AM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
>
> VMS (officially OpenVMS; I hated that marketing name when it was first
> proposed and I hate it now) is still alive and supported by a company
> called VMS Software, Inc. (VSI). Here is a pointer to their document
> OpenVMS Programming Concepts, Volume II, which describes the CLE in
> detail:
>
>
I think it's worth mentioning that the OpenVMS Hobbyist Program is still
alive and well and recently began supplying x86_64 licenses to hobbyists,
so if you have a reasonably modern amd64 system, you can run it under QEMU.
This came up lately in the riscv firmware universe. Someone named early
boot bt0, I mentioned crt0, and ... when did that name first appear? I
first saw it in v6 but I'm sure it was long before.
> Not a citation, either, but I believe the original RUNCOM came from CTSS (https://multicians.org/shell.html)
Yes, the CTSS command "runcom" arranged for commands stored in a file
to be run in the background. Such a file (which could contain at most
six commands) became known as "a runcom".
The term "script" did not emerge until Unix. I vaguely recall that Lee
McMahon coined the usage, but would welcome more reliable info about
its origin.
Doug
Clem Cole:
> Apologies to TUHS - other than please don't think Fortran did not
> impact UNIX and its peers.
Fortran had an important (if indirect) influence in early Unix. From
Dennis's memories of the early days of Unix on the PDP-7:
Soon after TMG became available, Thompson decided that we could not
pretend to offer a real computing service without Fortran, so he sat
down to write a Fortran in TMG. As I recall, the intent to handle
Fortran lasted about a week. What he produced instead was a definition
of and a compiler for the new language B.
(The Evolution of the Unix Time-Sharing System; see the 1984
UNIX System issue of the BLTJ for the whole thing, or just read
https://www.bell-labs.com/usr/dmr/www/hist.html)
Now let's move on to the name `rc'. Not the shell, but the
usage as part of a file name. Those two characters appear
at the end of the many annoying, and mostly pointless, configuration
files that litter one's home directory these days, apparently
copied from the old system-startup script /etc/rc as if the
name means `startup commands' (or something beginning with r,
I suppose, instead of startup). But I recall reading somewhere
that it just stood for `runcom,' a Multics-derived term for what
we now call a shell script.
I can't find a citation to back up that claim, though. Anyone
else remember where to look?
Norman Wilson
Toronto ON
