Hoi,
personally I use fmt(1) a lot for email formatting and such.
Typically I only use the `-w' parameter. Now someone asked me about
`-t' and `-c' of *GNU* fmt(1). I wasn't able to find good documentation
on them. The manpage only tells that they have to do with different
indentation for the first or first two lines. But what are the use
cases? How would source text for these parameters look like?
A look into the description and rationale sections of POSIX, which
often provides helpful information, was not possible because fmt(1)
is not part of POSIX (only fold(1) is). Why's that? Is it because
fmt(1) differs so much between Unix implementations? On BSD `-c'
centers text and `-t' sets tab widths. Plan 9 has none of these
options. But still, `-w' could have been standardized. Or was the
line filling algorithm different as well? How does fold(1) fit into
the picture?
Maybe you can answer some of these questions or give hints on where
I could find answers myself.
meillo
> I've stumbled across LSX, and I have it running on SimH. I'm quite inexperienced with Unix, but it's something I want to learn well, having brushed against it at university in the '80s, and having played with Linux somewhat.
I think you will experience a sizeable learning curve. You will be working with Unix and C as it stood around 1975 and that is substantially different from what it was in the 80’s. That said, I know from personal experience that it is an intriguing journey and certainly not impossible to do.
> Some help would be nice, but more generally, is anyone on this list more than vaguely familiar with LSX, or 6th Edition itself?
Many on this list are familiar with 6th edition. The best way to learn the internals of 6th edition is the “Lions’ book”:
https://www.amazon.com/Lions-Commentary-Unix-John/dp/1573980137
Coming from today’s perspective (or a 1980’s one), you will find the following key challenges:
- The version of C used for 6th edition is different from the 1980’s. Amongst other things the syntax of the assignment operators changed (not += but =+), the syntax for initialisation changed (not 'int a = 3', but 'int a 3’), the ‘long’ datatype (32 bit on a PDP-11) did not exist, the ‘void’ keyword did not exist, structs could not be assigned, passed or returned (only pointers to structs), etc.
- The stdio library did not exist yet, in its place there was the ‘portable i/o library’. This may be the hardest part to get used to.
- The file system was 16-bit based throughout. This has implications for stat(), lseek() did not exist (its precursor seek() used additional whence values to move the file pointer in 512 byte increments), etc.
When it comes to LSX, there are a few people who have experience with it on the this list (that I know of - there may be many more).
First of all, Heinz Lycklama, the original creator of LSX, appears to read this list from time to time.
Second, Leonid Broukhis and Serge Vakulenko (who managed to recover the LSX sources 20 years ago) might be reading the list. They took the trouble to port LSX to the Soviet BK-0010 computer, an LSI-11 type system some 15 years ago:
https://github.com/sergev/bkunix
You can stand on their shoulders, as they already took the trouble to convert the kernel source from 1975 C to 1980’s C and to create a stdio compatible library for it; they are using the 2.11BSD C compiler, which generates tighter code than the 1975 compiler — hence they could squeeze a bit more functionality in.
Third, I found the BK-0010 port some 5 years ago and used that as base to create a version that would run on a small TI990 clone:
http://www.stuartconner.me.uk/mini_cortex/mini_cortex.htm
This work later evolved into a stock 6th edition kernel and is now a curious mix of stuff dating from 1975 to 1985.
Your main challenge will be that neither the BK-0010 work nor my work will run on your hardware as-is. I think you have two possible paths forward. The first is to learn C and the library as it stood in 1975, the second is to take the BK-0010 code and to make it run on a stock LSI-11 again.
The title of the fmt man page in v9 was "ultra-simple text formatter".
Gnu dropped the "ultra" in favor of AI. Sometimes it does a pretty
job. Sometimes it messes up my typing style. Always it produces a
an apparently wavering right margin, as it assigns a separate
"optimal" line length to each paragraph. It's hard to imagine how
this command could stray from classic Unix simplicity and
intelligibility, but Gnu pulled it off.
Doug
Greetings,
What's the canonical source for patches to 2.9BSD and 2.11BSD?
I see we have 2.11BSD patch 469 dated last month in the archive. Where does
it come from? Has anybody climbed the hill to import all the patches into a
git repo? I've found some mirrors, but moe.2bsd.org has been down for me
for ages... How does Warren keep things up to date?
I also have a (maybe faulty) memory of a similar series of patches to
2.9BSD because it was the last BSD to support non-split I&D space machines.
yet a quick google search turns up nothing other than a set of patches
dated August 1985 (also in our archive) and some changes for variants of
hardware (pro, mscp). Is that it?
Warner
re: main.
i was surprised not to see any mention of the entry keyword reserved but, i believe, never used in early c. it is listed in k&r ed1.
i always assumed this was to allow the author to choose an alternative to main() for the program’s entry point, but we all know what assumption is...
-Steve
> From: Tyler Adams
> C is so prolific and influential because it's so easy to write a C
> compiler.
I'm not sure the implied corollary ('it's _not_ easy to write compilers for
other languages') is correct.
As a datapoint, I pulled "Algol 60 Implementation" (Randell and Russell) off
the shelf, and it reveals that the Algol 60 compiler discussed there (for the
KDF9), using lessons from the Algol compiler for the Electrologica X1, was
3600 words (roughly 3 instructions/word). So it was small.
Now, small is not necessarily equivalent to easy, but it was clearly not a
mountainous job. I imagine early BCPL, etc compilers were roughly similar.
The only language from that era which I can think of which was a slog,
compiler-wise, was PL/I.
I suspect the real reason for C's sucess was the nature of the language.
When I first saw it (ca. 1976), it struck me as a quantum improvement over
its contemporaries.
Noel
C main programs define “main”.
This also seems to be true of B main programs, according to the Johnson/Kernighan manual
The 1967 Martin Richards BCPL manual doesn’t explain how programs get started
The 1974 update from Martin Richards says there should be an OS addendum that explains this.
The 1974 University of Essex BCPL manual says to use START
The 1979 Parc Alto BCPL manual uses Main and I think that must be unchanged from 1972.
The AMSTRAD BCPL guide from 1986 uses start()
So who started “main” and when? I can’t find an online copy of the Bell Laboratories BCPL manual (Canaday/Thompson) from 1969 or anything about how to use BCPL on Multics or CTSS.
-L
Lawrence Stewart <stewart(a)serissa.com> asks on Fri, 22 May 2020 14:43:40 -0400:
>> So who started "main" and when?
I have just checked several PDFs of IBM mainframe and Fortran manuals
going back to 1954.
The early manuals did not appear to use the name "main", but in
ibm-7030/C22-6578_7030_Programming_Examples_Apr61.pdf, the phrase "the
main program" occurs in the context of assembly language coding.
In ibm-7030/C22-6751_7030_FORTRAN_IV_May63.pdf, on page 22,
which begins with
Part II. FORTRAN Programming for the IBM 7030
the first paragraph ends with "the main program".
In silliac/SPMpart1-ocr.pdf, titled
Silliac Programming Manual
The Adolph Basser Computing Laboratory
School of Physics
The University of Sydney
and dated January 1959, on page 99, I find
>> ...
>> In this way a program is seen to consist of several distinct,
>> self-contained blocks, namely the various subroutines and the part of
>> the program (usually called the main program or master routine) which
>> ^^^^^^^^^^^^^^^^
>> makes use of its subroutines by sending control to them.
>> ...
I have many manuals for older systems, but most have not been
subjected to optical-character recognition, so it is difficult to find
specific text in them. Nevertheless, I have demonstrated that by at
least January 1959, the phrase "main program" was common enough to
appear in computer documentation, qualified by "usually".
Some day, perhaps I'll find time to do OCR conversion on my extensive
PDF file archives.
I'll be pleased to hear of earlier uses of "main program" from TUHS
list members.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
> I went looking for the three IPC reports:
>
> For more information about this system, see:
> - "Interprocess Communication Extensions for the UNIX Operating System: I -
> Design Considerations", Rand Corporation, Report R-2064/1-AF, June 1977.
> - "Interprocess Communication Extensions for the UNIX Operating System: II
> - Implementation", Rand Corporation, Report R-2064/2-PR, April 1977.
> - "UNIX TCP User's Guide", Bolt Beranek and Newman Inc., Report No. 3724
>
>
> And could only find the first one online at
>
> https://apps.dtic.mil/dtic/tr/fulltext/u2/a044200.pdf
>
> Do we have the other two anywhere?
Yes we do.
The first two are about Rand ports. You’ve found the overview by Carl Sunshine, the implementation by Steve Zucker is the next report up on DTIC:
https://apps.dtic.mil/sti/pdfs/ADA044201.pdf
The TCP User guide report you refer to is about a TCP implementation done by Jack Haverty, which took an implementation in PDP-11 assembler and wrapped it in a NCP Unix shell. Jack has a listing in his attic, but it is not scanned. The problem with this implementation was that it is was all very cramped in the kernel, so he had to reduce disk buffers substantially. As pipes (and Rand ports) use disk buffers to hold pipe data, which get swapped out to disk as needed, he found that his system trashed a lot and effective TCP speeds in his first trials were barely above few dozen byte per second.
The report is actually on the TUHS tree:
https://www.tuhs.org/cgi-bin/utree.pl?file=BBN-V6/doc
(there is also nroff source for Steven Zucker’s report, and other interesting material in that directory - such as a report on pipe performance).
The actual V6 implementation that is on that THUS page is not Jack Haverty’s version, but a version done from scratch by Mike Wingfield, using the learning’s of Jack’s work. Mike’s implementation worked quite well and won first prize in a March 1979 tongue-in-cheek TCP4 conformance & interop competition. The BBN report for that version is 4295. Craig Partridge was kind enough to dig it up from the BBN library - I can send you a copy if you like (it was cleared for public release).
Although the implementation was done for research purposes (mainly Autodin II security features and simulation), it seems to have had a long life as a stop-gap to keep aging PDP-11’s connected after the switch from NCP to TCP in 1983.
Paul
