TUHS November 2017

tuhs@tuhs.org

82 participants
124 discussions

by Will Senn

Hi, In looking around the system v7 environment, I don't see a more command anywhere. I downloaded, converted, and attached 1bsd, 2bsd, and finally 3bsd and it was there that I found source for more... 3bsd looks like it's for VAX, not PDP-11, and it doesn't want to compile (looking for some externs that I gather are part of the distro's clib). I may jump ship on V7 and head over to 2.9BSD, which, as I understand it, is a V7 with fixes and these kind of additional tools... In the meantime, how did folks page through text like man sh and such before more? I know how to view sections of text using sed and ed's ok for paging file text (painful, but workable). I just can't seem to locate the idiomatic way of keeping everything from constantly scrolling out of view! Obviously, this isn't a problem on my mac as terminal works fine, but I like to try to stay in character as a 1970 time traveling unix user :). Thanks, Will Sent from my iPhone

7 years, 1 month

Re: [TUHS] 80 columns

by Doug McIlroy

> I do recall 80 column monitors, but I started on 132 column decwriter > IIs and hence have never had sympathy for 80 columns. It's weird that so Interesting. I wonder if that's where the 132 column (alternative) standard came from. No. IBM's printers were 132 columns even before stored-program computers.

7 years, 1 month

Re: [TUHS] margins and indenting, and arbitrary c rules

by jnc＠mercury.lcs.mit.edu

> From: Steve Simon > At the risk of stirring up another hornets nest... I usually try not to join in to non-history threads (this list has too much random flamage on current topics, IMNSHO), but I'll make an exception here... > this means my code is usually fairly narrow. I have what I think are somewhat unusual thoughts on nesting depth, etc, which are: keep the code structure as simple as possible. That means no complex nested if/then/else structures, etc (more below). I'd been moving in this direction for a while, but something that happened a long time ago at MIT crystalized this for me: a younger colleague brought me a routine that had a complex nested if/etc structure in it, which had a bug; I don't recall if he just wanted advice, or what, but I recall I fixed his problem by..... throwing away half his code. (Literally.) That really emphasized to me the downside of complexity like that; it makes it harder to understand, harder to debug, and harder for someone else (or you yourself, once you've been away from it for a while) to modify it. I've been getting more formal about that ever since. So, how did I throw away half his code? I have a number of techniques. I try not to use 'else' unless it's the very best way to do something. So instead of: if (some-conditional) { <some code>; } else { <some other code>; } (iterated, recursively) do: if (some-conditional) { <some code>; xxx; } <some other code>; where xxx is a 'return', or a 'break', or a 'continue'. That way, you can empty your brain once you hit that, and start with a clean slate. This is also an example of another thing I do, which is use lots of simple flow-control primitives; not go-tos (which I abhor), but loop exits, restarts, etc. Again, it just makes things simpler; once you hit it, you can throw away all that context/state in your mind. Keep the control flow structure as simple as possible. If your code is several levels of indent deep, you have much bigger problems than fitting it on the screen. I wrote up a complete programming style guide for people at Proteon working on the CGW, which codified a lot of this; if there's interest, I'll see if I can find a copy (I know I have a hardcopy _somewhere_). Noel

7 years, 1 month

Re: [TUHS] pre-more pager?

by Norman Wilson

Random832: ... and "p" (which is very minimalistic, despite using a few V8-specific library features, but V8 isn't in the web-accessible source archive) from Version 8 research unix. ==== p actually originated outside Bell Labs. I think it was written in the late 1970s at the University of Toronto. I first saw it at Caltech, on the UNIX systems in the High Energy Physics group that I ran for four years. The first few of those systems were set up by Rob Pike, who was at Caltech working on his masters degree (in astrophysics, I think); p was there because Rob brought it. For those who don't know it, p has quite an elegant design. Its default page size is 22 lines, which nicely fit the world of its time: allowed a couple of lines of context between pages on a 24-line CRT; evenly divided the 66-line pages (still!) output by nroff and pr. It uttered no prompt and required neither raw nor cbreak nor even no-echo mode: it printed the final line of each page sans newline; to continue, you typed return, which was echoed, completing that line before the next was printed. It buffered text internally to allow backing up a few pages, so it was possible to back up even when input didn't come from a file (something I'm not sure the more of the time could do). Internally the buffering was done with a standalone library that could have been used in other programs, though I don't know whether it ever was. p also led me to an enlightening programming story. One day I was looking over the code, trying to understand just how the buffering worked; part of it made no sense to me. To figure it out, I decided to write my own simple, straightforward version with the same interface; test and debug it carefully; then lay printouts of the two implementations side-by-side, and walk through some test cases. This revealed that the clever code I couldn't make out in the original was actually buggy: it scrambled data (I forget the details) when read returned less than a full buffer. p (my version) is one of the several programs I bring along to every new UNIX-derivative environment. I use it daily. I have also recently noticed a new bug: on OpenBSD, it sometimes scrambles the last few lines of a file. I have figured out that that has something to do with whether fclose (my version uses stdio) is called explicitly or by exit(3), but I don't know yet whether it's the library's fault or my own. Even the simplest programs have things to teach us. Norman Wilson Toronto ON

7 years, 1 month

Re: [TUHS] margins and indenting, and arbitrary c rules

by jnc＠mercury.lcs.mit.edu

> From: Don Hopkins > https://stackoverflow.com/questions/268132/invert-if-statement-to-reduce-ne… Thanks for that - interesting read. (Among other things, it explains where the 'only have one return, at the end' comes from - which I never could understand.) > Nested if statements have more 'join' points where control flow merges > back together at the end instead of bailing out early Exactly. In high-level terms, it's much like having a ton of goto's. Yes, the _syntax_ is different, but the semantics - and understanding how it works - is the same - i.e. hard. Noel

7 years, 1 month

Re: [TUHS] pre-more pager?

by Doug McIlroy

>> head -20 < filename > > too bad head doesn't exist on v7. sed -20q: same effect, same amount of typing.

7 years, 1 month

C question for the historians

by Arthur Krewat

From a mailing list I belong to, a back-and-forth is going on that I am not involved in. The following sums it up nicely: > It's really the implied equality that's the problem. For example: > > if (flags & DLADM_OPT_PERSIST) { > > would be better written as: > > if ((flags & DLADM_OPT_PERSIST) == 0) { Seriously? What do (or would) "original C" programmers think of this? To me, anything non-zero is "true" so the first is perfectly acceptable. The original assertion in the discussion was that the following is not "right" because of the mixing of bitwise and boolean. > if ((flags & DLADM_OPT_PERSIST) && (link_flags & DLMGMT_PERSIST)) { art k.

7 years, 1 month

margins and indenting, and arbitrary c rules

by Steve Simon

At the risk of stirring up another hornets nest... I never accepted the Microsoft “write functions for maximal indentation, with only one return” and stick to “get out if the function asap, try to have success at the bottom of the function” style. this means my code is usually fairly narrow. -Steve

7 years, 1 month

cryptic cc error on v7

by Will Senn

I found head on 3BSD and thought it might be as simple to compile as cr3, unfortunately, it isn't. I did: $ cc head.c head.o? $ cc -c head.c head.o? $ pcc head.c head.c head.o? I thought the assembler, as, was cryptic, at least there you get a one character error response. What is cc trying to say? Obviously head.o won't exist unless cc succeeds... Thanks, Will -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF

7 years, 1 month

Re: [TUHS] origins of void* -- Apology!

by Nemo

On 6 November 2017 at 19:36, Ron Natalie <ron(a)ronnatalie.com> wrote: > It’s worse than that. “char” is defined as neither signed nor unsigned. > The signedness is implementation defined. This was why we have the inane > “signed” keyword. What was that story about porting an early UNIX to a machine with different char polarity? I dimly recall only a few problems. N.

7 years, 1 month

← Newer
1
...
7
8
9
10
11
12
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS November 2017