> In the meantime, how did folks page through text like man sh
Chuckle. "Text like man sh" wasn't very long back then.
.,.20p was quite an effective pager. It could go backward,
and it didn't wipe out the screen (which can destroy the
record of the problem that caused you to consult a reference).
I still do it from time to time.
Doug
>
> Regarding the links and old bsd's. The binary cr3 on 1bsd works in v7.
> Also, the book I'm reading has a c program that does paging. But, I'm
> always off down the rabbit hole... I tried to compile the cr3.c source
> and I get this error:
>
> # cc cr3.c
> Undefined:
> _fout
> _flush
> _getc
> _end
>
> My understanding is that cc includes libc by default, so these must not
> be in libc. But getc is standard lib, so what am I missing?
That source is for V6 not V7. V6 did not have the stdio lib yet, but a precursor to that.
The binary you are using has the older io routines statically linked in.
Paul
From: Ron Natalie
> We actually still had some real DEC DH's on our system.
> ...
> At least the DZ doesn't loop on the ready bit like the kernel printf
This reminds me of something I recall reading about John McNamara (designer of
the DH11) admitting that he'd screwed up a bit in the DH design; IIRC it was
that if you set the input silo alarm (interrupt) level to something greater
than 1 character, and someone types one character, and then nothing
else... you never get an input interrupt!
(Which is why some Unix DH driver which sets the silo alarm level > 1 - to get
more efficient processing by reducing the number of interrupts _if possible_ -
has to call a 'input characters ready from the DH' routine in the clock
interrupt code.)
IIRC McNamara said he should have included a timeout, so that if the silo
count was non-zero,and stayed that way for a while, it should have caused
a timeout, and an interrupt.
I was just looking for this, but couldn't find it. I thought it was here:
http://woffordwitch.com/McNamaraDH11.asp
but it doesn't seem to be. Does anyone recall seeing this anywhere, and if so,
where? Web search engines didn't turn anything up, alas...
Noel
> From: Clem Cole
> many (most) Unix sites used Able DHDM's which were cheaper than DEC DZ's
Oh, our DZ's weren't DEC, but some off-brand (I forget what). We were too poor
to afford DEC gear! :-) (Our machines, first a /40, and later a /45, were
hand-me-down's.)
Noel
> From: Will Senn
> how did folks page through text like man sh and such before more?
We wrote our own versions of more. Here is one from the roughly-PWB1 systems
at MIT:
http://ana-3.lcs.mit.edu/~jnc/tech/unix/s2/p.c
but on looking at it, I'm not 100% sure it's the one I used there (which is
documented in the MIT UPM).
Here's one I wrote for myself for use on V6:
http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#UCmds
before I retrieved all the MIT sources (above), if you want somthing to
actually use on V6/V7.
Noel
I wrote a snippet from my K&R C studies to convert tabs and backspaces
to \t \b to display them, the code looks like this:
/* ex 1-8 */
main()
{
int c, sf;
while((c = getchar()) != EOF) {
if(c == '\t')
printf("\\t");
if(c == '\b')
printf("\\b");
else
putchar(c);
}
}
I'm not looking for code review, but the code is intended to replace the
tabs and backspaces with \t and \b respectively, but I haven't been able
to test it because I can't seem to make a backspace character appear in
input. In later unices, ^V followed by the backspace would work, but
that's not part of v7. Backspace itself is my erase character, so
anytime I just type it, it backspaces :).
Thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
Arthur Krewat <krewat(a)kilonet.net> writes on Mon, 6 Nov 2017 19:34:34 -0500
>> char (at least these days) is signed. So really, it's 7-bit ASCII.
I decided last night to investigate that statement, and updated my
C/C++ features tool to test the sign and range of char and wchar_t.
I ran it in our test lab with physical and virtual machines
representing many different GNU/Hurd, GNU/Linux, *BSD, macOS, Minix,
Solaris, and other Unix family members, on ARM, MIPS, PowerPC, SPARC,
x86, and x86-64 CPU architectures. Here is a summary:
% cat *.log | grep '^ char type is' | sort | uniq -c
157 char type is signed
3 char type is unsigned
The sole outliers are
* Arch Linux ARM on armv7l
* IBM CentOS Linux release 7.4.1708 on PowerPC-8
* SGI IRIX 6.5 on MIPS R10000-SC
for which I found these log data:
Character range and sign...
CHAR_MIN = +0
CHAR_MAX = +255
SCHAR_MIN = -128
SCHAR_MAX = +127
UCHAR_MAX = +255
char type is unsigned
signed char type is signed
unsigned char type is unsigned
The last two lines are expected, but my program checked for an
incorrect result, and would have produced the string "WRONG!" in the
output; no system had that result.
-------------------------------------------------------------------------------
- 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/ -
-------------------------------------------------------------------------------
Apologies in advance if this is found too far off list or offensive. But
some how I think many on this list might find it amusing. One of my
friends who stayed academic sent this me…. his comment was this surfaced
when students were asking for better music to code to:
https://www.youtube.com/watch?v=0rG74rG_ubs
Warning language is not PG but the it is ‘rapper cursing’ and might even be
allowed over the airwaves without ‘beeping’ by some stations. That said,
I suggest/recommend head phones so not to offend someone by the language.
Many thanks for all that background to the origins of void pointers.
Now for applying that to the early sockets API.
In the first (1981) and second (4.1a, April 1982) revision of that API, socket addresses were passed as a fixed 16-byte structure, essentially the same as the current struct sockaddr. By the time of the third revision (4.1c/4.2, 1983) of that API it had become a variable sized opaque object, passed around as a pointer and a size.
The 1983 4.2BSD system manual (http://www.cilinder.be/docs/bsd/4.2BSD_Unix_system_manual.pdf) describes it that way, e.g. defining connect() as:
connect(s, name, namelen);
int s; caddr_t name; int namelen;
Note the use of caddr_t in the user level signature. Yet, the actual source code for 4.1c/4.2 BSD only uses caddr_t in the kernel (as pointed out on this list), but continues to use struct sockaddr * in the user land interface. It would seem to me today that void * would have been a more logical choice and with void * having been around for about 3 years in 1983, it might have seemed logical back then as well -- after all, this use case is similar to the malloc() use case. It would have avoided the need for a longish type cast in socket api calls (without further loss of type safety, as that was already lost with the required cast from e.g. struct sockaddr_un* to struct sockaddr* anyway).
Related to this, from the "4.2bsd IPC Primer” (1983, https://www2.eecs.berkeley.edu/Pubs/TechRpts/1983/CSD-83-145.pdf , page 5), it would appear that the format of socket addresses was perhaps unfinished business:
- Apparently at some point in time simple strings were considered as unix domain addresses, i.e. not a sockaddr_un structure. Maybe it was limping on this thought that caused the prototype soackaddr structure not to have a size field — having had that would have simplified the signature of many socket API functions (interestingly, it would seem that such a size field was added in 4.3BSD some 6, 7 years later).
- The examples show no type casts. This may have been for didactical clarity, but perhaps it also suggests a signature with void* semantics.
I’d be happy for any background on this.
Also, about halfway down this page http://tech-insider.org/vms/research/1982/0111.html there is mention of CSRG technical report #4, "CSRG TR/4 (Proposals for the Enhancement of Unix on the Vax)”. I think this may be the initial discussion document from the summer of 1981 that evolved into the 4.2 system manual. Would anybody have a copy of that document?
Paul
Ok... so I got vi to work full screen in a telnet session to the DZ port in V8. BTW TERM=vt132 seems to be the best option given the existing termcap. Yay. Now I'm a happy camper with my v8 instance and I'm reading Rochkind's book and learning lots more about everything from unix error codes to system programming etc. V8 is much more familiar ground to me than earlier versions (mostly vi) at this point.
Anyway, my first question of the day is this - is vt132 the best that I can do terminalwise?
I'm not totally up to speed on terminals in ancient (or modern) unices, but I've been reading, and it seems that if I can match a termcap entry to my emulated terminal with a majority of available capabilities, that I would reach screen nirvana in my instance. Now, it also seems like my mac will emulate different terminals and defaults to something like xterm-256. I don't expect color to be supported, but I don't really know. This leads to a second question, if I take an xterm termcap entry and put it in my termcap file, will it work better than the vt entries?
Is my logic correct, or am I thinking incorrectly about this?
Sidenote: now that I'm in v8 and having used v6 and v7 - McIlroy's reader actually is much, much more interesting and handy! Thanks, Doug!
Sent from my iPhone
Sent from my iPhone
