The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] run commands at login in v6 and stty
@ 2022-02-26 20:39 Will Senn
  2022-02-26 21:03 ` Michael Kjörling
  2022-02-26 22:49 ` Clem Cole
  0 siblings, 2 replies; 20+ messages in thread
From: Will Senn @ 2022-02-26 20:39 UTC (permalink / raw)
  To: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

Login commands question:

I'm sure it's simple, but I can't figure it out. How do I get something 
to run at login in v6? Right now, I use ed to create a file 'setprof' 
that contains:

    stty erase[space][backspace][return]
    stty nl0 cr0

Then after logging in:

    sh setprof

It works, but, it is pretty clunky.

stty question:

So, I looked at stty.c and it looks like the following should work, if 
the terminal is sending ^H for backspace:

    #define BS0     0
    #define BS1     0100000

    modes[]
    ...
             "bs0",
             BS0, BS1,

             "bs1",
             BS1, BS1,


but:

    stty bs0
    or
    stty bs1

don't result in proper backspace handling..

but:

    stty[space][^h][return]


works...

Thoughts?

[-- Attachment #2: Type: text/html, Size: 1854 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-26 20:39 [TUHS] run commands at login in v6 and stty Will Senn
@ 2022-02-26 21:03 ` Michael Kjörling
  2022-02-26 22:49 ` Clem Cole
  1 sibling, 0 replies; 20+ messages in thread
From: Michael Kjörling @ 2022-02-26 21:03 UTC (permalink / raw)
  To: tuhs

On 26 Feb 2022 14:39 -0600, from will.senn@gmail.com (Will Senn):
> I'm sure it's simple, but I can't figure it out. How do I get something to
> run at login in v6?

From a very quick perusal of
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s2/sh.c it
doesn't look like you can, at least not in the way we're used to today
of having the shell execute a magic file (such as ~/.bashrc) during
startup. I also don't see anything in
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/etc/passwd that
suggests that the shell can be specified on a per-user basis the way
we're used to being able to do today, so the hack of making that point
to a program that does some initial setup and then launches the shell
proper also might not be readily available.

On the other hand,
https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/sh/main.c
looks like it includes such support; see the section surrounding the
pathopen(nullstr, profile) call toward the bottom of main(). (Beware:
it's written in Bourne C.)

I won't say "you can't do it in V6", because I don't know things
anywhere near well enough to say that, but it doesn't look entirely
trivial at least, and it seems to have been added in V7's sh.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-26 20:39 [TUHS] run commands at login in v6 and stty Will Senn
  2022-02-26 21:03 ` Michael Kjörling
@ 2022-02-26 22:49 ` Clem Cole
  2022-02-26 23:12   ` Rob Pike
  1 sibling, 1 reply; 20+ messages in thread
From: Clem Cole @ 2022-02-26 22:49 UTC (permalink / raw)
  To: Will Senn; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

Some thoughts ..

1.) the precursor to the csh is the newshell in {1}BSD.  It's Joy's hack to
the Thompson shell and you might find it more usable.
2.) PWB 1.0 is based on a V6 kernel and has the Mashey Shell, which is in C
and predates Bourne's  It might also be easier for you to use.
3.) srb wrote his shell during the transition between V6, TS and V7.   At
least one version ran on the V6++ system we had at CMU, but of course as
pointed out, it is written in Bourne-Gol. And I'm pretty sure his CPP
definitions will need at least a gen2 /lib/cpp implementation***  However,
Steve was also doing it at the time when the compiler was being updated.
FWIW: We also had the 'Typesetter C' running on our V6 system in those
days.  So my >>guess<< is that v6 + Typesetter C - will compile the V7
shell.

Clem



*** Rob or Steve Johnson - maybe remembers when cpp first appeared.  I
don't remember if it was part of V5 or not - those bits have faded from my
brain.  What I do remember is there were a couple of different cpp's early
on.  The first one was pretty crude by today's standards, albeit it was a
cool idea and it was the one thing I really liked about C over BLISS early
on [BLISS had Macros, which was cool aalso, but cpp could do things Bliss
could not].

[-- Attachment #2: Type: text/html, Size: 2324 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-26 22:49 ` Clem Cole
@ 2022-02-26 23:12   ` Rob Pike
  2022-02-27  0:46     ` Clem Cole
  2022-02-27 15:01     ` Larry McVoy
  0 siblings, 2 replies; 20+ messages in thread
From: Rob Pike @ 2022-02-26 23:12 UTC (permalink / raw)
  To: Clem Cole; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1790 bytes --]

Cpp was definitely in v6, and I'm pretty sure it was in earlier editions.
The first pass of the C compiler would invoke it if the first byte of the
source file was a '#'. However, the early version only did #define and
#include. It was rewritten for v7, I believe, introducing the catastrophe
of #ifdef, while the existential horror of #if was later still, foisted on
us by someone not in Research.

-rob


On Sun, Feb 27, 2022 at 9:53 AM Clem Cole <clemc@ccc.com> wrote:

>
> Some thoughts ..
>
> 1.) the precursor to the csh is the newshell in {1}BSD.  It's Joy's hack
> to the Thompson shell and you might find it more usable.
> 2.) PWB 1.0 is based on a V6 kernel and has the Mashey Shell, which is in
> C and predates Bourne's  It might also be easier for you to use.
> 3.) srb wrote his shell during the transition between V6, TS and V7.   At
> least one version ran on the V6++ system we had at CMU, but of course as
> pointed out, it is written in Bourne-Gol. And I'm pretty sure his CPP
> definitions will need at least a gen2 /lib/cpp implementation***  However,
> Steve was also doing it at the time when the compiler was being updated.
> FWIW: We also had the 'Typesetter C' running on our V6 system in those
> days.  So my >>guess<< is that v6 + Typesetter C - will compile the V7
> shell.
>
> Clem
>
>
>
> *** Rob or Steve Johnson - maybe remembers when cpp first appeared.  I
> don't remember if it was part of V5 or not - those bits have faded from my
> brain.  What I do remember is there were a couple of different cpp's early
> on.  The first one was pretty crude by today's standards, albeit it was a
> cool idea and it was the one thing I really liked about C over BLISS early
> on [BLISS had Macros, which was cool aalso, but cpp could do things Bliss
> could not].
>

[-- Attachment #2: Type: text/html, Size: 3135 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-26 23:12   ` Rob Pike
@ 2022-02-27  0:46     ` Clem Cole
  2022-02-27 15:01     ` Larry McVoy
  1 sibling, 0 replies; 20+ messages in thread
From: Clem Cole @ 2022-02-27  0:46 UTC (permalink / raw)
  To: Rob Pike; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]

Yes. Thanks.  I do remember it in 6 and the hack in cc to run it or not(it
took years for me to break the habit of starting a C program with a #) but
what I don’t remember was it in v5 - which we only ran briefly (I
personally never saw V4 either although I know Columbia and I believe
Harvard had it)

Clem

On Sat, Feb 26, 2022 at 6:12 PM Rob Pike <robpike@gmail.com> wrote:

> Cpp was definitely in v6, and I'm pretty sure it was in earlier editions.
> The first pass of the C compiler would invoke it if the first byte of the
> source file was a '#'. However, the early version only did #define and
> #include. It was rewritten for v7, I believe, introducing the catastrophe
> of #ifdef, while the existential horror of #if was later still, foisted on
> us by someone not in Research.
>
> -rob
>
>
> On Sun, Feb 27, 2022 at 9:53 AM Clem Cole <clemc@ccc.com> wrote:
>
>>
>> Some thoughts ..
>>
>> 1.) the precursor to the csh is the newshell in {1}BSD.  It's Joy's hack
>> to the Thompson shell and you might find it more usable.
>> 2.) PWB 1.0 is based on a V6 kernel and has the Mashey Shell, which is in
>> C and predates Bourne's  It might also be easier for you to use.
>> 3.) srb wrote his shell during the transition between V6, TS and V7.   At
>> least one version ran on the V6++ system we had at CMU, but of course as
>> pointed out, it is written in Bourne-Gol. And I'm pretty sure his CPP
>> definitions will need at least a gen2 /lib/cpp implementation***  However,
>> Steve was also doing it at the time when the compiler was being updated.
>> FWIW: We also had the 'Typesetter C' running on our V6 system in those
>> days.  So my >>guess<< is that v6 + Typesetter C - will compile the V7
>> shell.
>>
>> Clem
>>
>>
>>
>> *** Rob or Steve Johnson - maybe remembers when cpp first appeared.  I
>> don't remember if it was part of V5 or not - those bits have faded from my
>> brain.  What I do remember is there were a couple of different cpp's early
>> on.  The first one was pretty crude by today's standards, albeit it was a
>> cool idea and it was the one thing I really liked about C over BLISS early
>> on [BLISS had Macros, which was cool aalso, but cpp could do things Bliss
>> could not].
>>
> --
Sent from a handheld expect more typos than usual

[-- Attachment #2: Type: text/html, Size: 4003 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-26 23:12   ` Rob Pike
  2022-02-27  0:46     ` Clem Cole
@ 2022-02-27 15:01     ` Larry McVoy
  2022-02-27 17:10       ` Clem Cole
  1 sibling, 1 reply; 20+ messages in thread
From: Larry McVoy @ 2022-02-27 15:01 UTC (permalink / raw)
  To: Rob Pike; +Cc: TUHS main list

On Sun, Feb 27, 2022 at 10:12:39AM +1100, Rob Pike wrote:
> Cpp was definitely in v6, and I'm pretty sure it was in earlier editions.
> The first pass of the C compiler would invoke it if the first byte of the
> source file was a '#'. However, the early version only did #define and
> #include. It was rewritten for v7, I believe, introducing the catastrophe
> of #ifdef, while the existential horror of #if was later still, foisted on
> us by someone not in Research.
> 
> -rob


As someone who has lived through a lot of #if / #ifdef et al, I've got
mixed feelings.  SGI definitely abused it, Dave Cutler was asked to
make NT work on MIPS and was given the IRIX kernel source as a guide.
That source was riddled with #ifdef <something>WAR where "WAR" stood for
"work around" (I might have the details wrong but definitely have the
idea correct).  All of those work arounds were kernel code that had to
be different because various MIPS chips had bugs.

Cutler's response was "Send me the kernel code when you have MIPS chips
that actually work".  He was disgusted and I don't blame him.

On the other hand, I grew up in the era that X11 was sort of new, all the
vendors had their own windowing system (Sunview comes to mind), and while
they all had something to be said for them (the Sunview API was really
nice), they all were different.  So people like me carried around an X11
source tree and built it on whatever platform I happened to be running
on today (I was a contractor early on, worked on lots of different boxes).

The X11 tree was a heavily ifdef-ed.  And it needed to be, I don't have
an answer as to how you would reuse all that code on different hardware
in a better way.  Yep, ugly, but having N copies of the same code,
all almost the same but a little different, yeah, that's a formula for
having bugs fixed in one of those copies but not the others.

So while I understand (I think) Rob's distaste for #ifdef, I've been
very grateful for it when I needed it.  I ran ctwm on X11 for decades
and everything "just worked" on Suns, SGIs, PowerPC, PARISC, etc.

--lm

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-27 15:01     ` Larry McVoy
@ 2022-02-27 17:10       ` Clem Cole
  0 siblings, 0 replies; 20+ messages in thread
From: Clem Cole @ 2022-02-27 17:10 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 397 bytes --]

On Sun, Feb 27, 2022 at 10:01 AM Larry McVoy <lm@mcvoy.com> wrote:

> So while I understand (I think) Rob's distaste for #ifdef, I've been very
> grateful for it when I needed it.
>
Yep - like symlinks -- useful feature when appropriately used in specific
moderation where they really do help.  But both are like giving whiskey to
teenagers, so don't be surprised when the result is catastrophic.

[-- Attachment #2: Type: text/html, Size: 1141 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-28 19:25       ` Dan Cross
@ 2022-02-28 21:25         ` markus schnalke
  0 siblings, 0 replies; 20+ messages in thread
From: markus schnalke @ 2022-02-28 21:25 UTC (permalink / raw)
  To: tuhs

Hoi.

[2022-02-28 14:25] Dan Cross <crossd@gmail.com>
>
> On a personal note, when I was learning to write C for Unix, I read a lot of
> open source code to see how to do it. So much of it was riddled with complex #
> ifdefs that I kind of got the impression that that was how things were
> _supposed_ to be written. Then I read the Spencer/Collyer paper, and modified
> some program that I'd written to use abstract interfaces; it was so much easier
> to reason about that I was kind of shocked that others didn't do the same.
> 
> I suppose the point is that many programmers learn by copying what has come
> before. However, so much of what's out there is a poor example of how to do
> things; we're stuck with a feedback loop of poor design.

... and I am very happy that I found my way into a different feedback
loop, called Unix philosophy ... with sources meant to be read, great
documentation, and books that actually feature real life code (already
a thing by itself) but also that the production code is on the same
``acts as a good example'' level.

If programmers have never experienced such wonderful worlds -- how
poor their programming lifes must be!


meillo

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-28 19:26       ` Clem Cole
@ 2022-02-28 20:03         ` Adam Thornton
  0 siblings, 0 replies; 20+ messages in thread
From: Adam Thornton @ 2022-02-28 20:03 UTC (permalink / raw)
  To: Clem Cole, The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1239 bytes --]

From the Spencer paper:

"In such cases,it is important to go back and fix the kludges. The time is
not wasted; it is an investment in the future"

Yeah, well, that's the problem, isn't it?  Investment in the future is not
incentivized.  The manager needs a win *now* so he can collect his bonus
and then leave for someplace that will pay him more.  Even as a lowly
engineer I've never seen a place where it made financial sense to stick
around.  You'd never get compensation, authority, and responsibility as
fast by being internally promoted as by hopping to the competition across
town.

If the goal were building a sustainable and maintainable ecosystem, then,
sure.  But it isn't.  Good software engineering doesn't pay.  Barfing out a
checklist of feature bullet points that marketing wants pays.

That does suggest that there's some scope for doing this properly in big
Open Source projects--except those, in reality, are almost always driven by
a very few large funders, who have particular features they want and are
willing to pay for.  Shipping those features then becomes the priority, not
keeping the codebase manageable.

I guess it comes down to "hate the game, not the player" on my part and I'm
having a grumpy day.

Adam

[-- Attachment #2: Type: text/html, Size: 2325 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-28 18:47     ` Dan Cross
  2022-02-28 19:25       ` Dan Cross
@ 2022-02-28 19:26       ` Clem Cole
  2022-02-28 20:03         ` Adam Thornton
  1 sibling, 1 reply; 20+ messages in thread
From: Clem Cole @ 2022-02-28 19:26 UTC (permalink / raw)
  To: Dan Cross; +Cc: TUHS main list, Douglas McIlroy

[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]

On Mon, Feb 28, 2022 at 1:49 PM Dan Cross <crossd@gmail.com> wrote:

>
> #ifdef has more or less always struck me as the solution to the wrong
> problem. "We have all this code and we want to shoehorn it into a new
> environment," instead of, "we have many environments, so we carefully
> structure the code to accommodate the differences." Of course, the latter
> is harder than the former, but it also pays larger dividends over time as
> compared to the former.
>
Absolutely - but the problem is the development process (more in a minute).

>
> The biggest problem with #ifdef wasn't so much that it existed, but rather
> that it was used for too many things that it wasn't well-suited for.
>
Agreed.



> The second biggest problem was that it was semantically unaware of the
> language; it was purely textual. Bummer.
>
Dan - I'll argue with you on that one actually.   One of the reasons why C
was successful in a professional language is that it could be easily
preprocessed, which other languages like Pascal and even Ada sucked
when you tried.  There are times when a preprocessor is just really handy
as Larry said, particularly in a product programming house.

And here is the issue ...

Doug and Rob are 100% right about Plan 9 but .. it's not a fair
comparison.  Plan9 was a research system.  X started out as that, but by
the time of X11 it was a production system and very different types of
programmers.   When you are porting code, particularly when under type
constraints, Larry described exactly how it's done ...   #ifdef NOTDEF  ...
  ok this works.... and off you go the next issue with the product. In my
experience, the development process often (tends to) reinforce this
behavior.

Note I am not telling you that's a good idea ... but *it is a typical
behavior* (*a.k.a. *whiskey to teenagers).  You intend to go back and redo
it, but it never gets done.  The next person adds their hack and pretty
soon you have the BSD kernel if #ifdef FASTVAXl or  #ifdef BIG_ENDIAN scattered
all over the code base.

As Larry and others have pointed out, an abstraction layer, when you can
enforce it, clearly is the best.   But to be fair, one of the reasons why C
was so popular, is that so much code could be moved.  One of the things I
hated about Pascal, was that so much code had been written that assumed 36
or 40 integers, or that string limits varied depending on byte or work size
and how the len was encoded -- yeech.

The problem, as Larry said, is that it is a powerful tool that was easy to
and often was, abused by both neophytes and people that should have known
better.

[-- Attachment #2: Type: text/html, Size: 5614 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-28 18:47     ` Dan Cross
@ 2022-02-28 19:25       ` Dan Cross
  2022-02-28 21:25         ` markus schnalke
  2022-02-28 19:26       ` Clem Cole
  1 sibling, 1 reply; 20+ messages in thread
From: Dan Cross @ 2022-02-28 19:25 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list, Douglas McIlroy

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

On Mon, Feb 28, 2022 at 1:47 PM Dan Cross <crossd@gmail.com> wrote:
> [snip]


Oops, I forgot to mention something. I imagine a lot of readers of this
list are familiar with this paper, but for those that aren't, this
resonates:

https://www.usenix.org/legacy/publications/library/proceedings/sa92/spencer.pdf

On a personal note, when I was learning to write C for Unix, I read a lot
of open source code to see how to do it. So much of it was riddled with
complex #ifdefs that I kind of got the impression that that was how things
were _supposed_ to be written. Then I read the Spencer/Collyer paper, and
modified some program that I'd written to use abstract interfaces; it was
so much easier to reason about that I was kind of shocked that others
didn't do the same.

I suppose the point is that many programmers learn by copying what has come
before. However, so much of what's out there is a poor example of how to do
things; we're stuck with a feedback loop of poor design.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 1324 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-28 14:07   ` Larry McVoy
@ 2022-02-28 18:47     ` Dan Cross
  2022-02-28 19:25       ` Dan Cross
  2022-02-28 19:26       ` Clem Cole
  0 siblings, 2 replies; 20+ messages in thread
From: Dan Cross @ 2022-02-28 18:47 UTC (permalink / raw)
  To: Larry McVoy; +Cc: TUHS main list, Douglas McIlroy

[-- Attachment #1: Type: text/plain, Size: 6578 bytes --]

On Mon, Feb 28, 2022 at 9:10 AM Larry McVoy <lm@mcvoy.com> wrote:

> So I'm curious, did Plan 9 run on a similar number of architectures and
> support a similar number of graphics cards?
>

Yes, it did.

If it did that, nicely, then you have a great point, the X11 people
> (and most of us) clearly missed a better way to do things.  If this is
> the case, I'd like to understand how you did it because just including
> different definitions doesn't begin to scratch the surface of what the
> #ifdefs did in X11, there were tons in the actual code.
>

#ifdef has more or less always struck me as the solution to the wrong
problem. "We have all this code and we want to shoehorn it into a new
environment," instead of, "we have many environments, so we carefully
structure the code to accommodate the differences." Of course, the latter
is harder than the former, but it also pays larger dividends over time as
compared to the former.

Maybe the constant system interface made all the difference, that
> could be.
>
> If it supported a much smaller number of targets, well, sure, it's
> easier to be clean if you have a clean set of targets.
>

In fairness, a meaningful comparison is hard: plan9 ran on ~a dozen
different architectures over its lifetime, but never supported near the
variety of software or workloads of Unix, and didn't exactly "compete" in
the market the way Unix did. The PC port in particular supported oodles of
graphics cards at one point, but not as many as X did, mostly because there
weren't all that many folks working with the unsupported cards, so there
wasn't a lot of motivation to write tons of drivers.

Could it have retained its elegantly clean structure over time had things
evolved differently? That's impossible to answer, but I'm sad that we never
got the chance to find out.

I remain grateful for the #ifdefs, I could make enough sense of it
> all to bring up X11 on every platform I worked on.  It wasn't pretty,
> there was a ton of "I don't recognize this $WHATEVER, what happens if
> I just #if 0 around the whole thing?  Wow, it compiles, lets see if
> I get a window system.  Yep, I do.  Shrug."  That limited what I had
> to understand to the much smaller subset of code I was actually
> going to run, yeah, that set of #ifdefs was a mess but not such
> a mess that I didn't get a working X11.


> I'm not arguing that #ifdef is good, I'm just acknowledging it had
> a lot of benefit to me, and _for me_, the cost was worth it in that
> instance.  I could have X11 working in less than a day.
>

I do think that #ifdef, used extremely judiciously, can have some utility:
for example, compiling out debug code by setting a constant.  Consider:

#ifdef NDEBUG
const bool DEBUGGING = false;
#else
const bool DEBUGGING = true;
#endif

static inline
void
DBG(const char *fmt, ...)
{
    if (DEBUGGING) {
        va_list ap;
        va_start(ap, fmt);
        vfprintf(stderr, fmt ap);
        va_end(ap);
    }
}

    DBG(foo);

if `NDEBUG` is defined, then the body of the static inline becomes, `if (0)
{ ... }` and one hopes our compilers are sufficiently smart to elide the
entire thing.

The biggest problem with #ifdef wasn't so much that it existed, but rather
that it was used for too many things that it wasn't well-suited for. The
second biggest problem was that it was semantically unaware of the
language; it was purely textual. Bummer.

I do get your point about abstracting the interface differences away,
> I actually hate #ifdefs in the code with a passion so in BitKeeper we
> had all that stuff buried under the abstractions.  We made everything
> look like Unix, even on Windows, except for fork().  I haven't called
> fork() directly in close to 20 years, we picked up spawn() and made that
> work everywhere.  The abstraction layer cuts down on the #ifdefs in the
> code a LOT.
>

Agreed. But getting those abstractions right requires experience and taste.
#ifdef is a blunt took for a nuanced problem.

        - Dan C.


On Mon, Feb 28, 2022 at 06:22:28PM +1100, Rob Pike wrote:
> > Plan 9 had the distinct advantage of a constant system interface at the
> > source level. X11 did not, but it also made essentially no attempt to
> > abstract it away, so the lines starting #ifdef often outnumbered the
> actual
> > code. I couldn't make hide nor hair of it, and had no way to reliably
> test
> > any change.
> >
> > C with #ifdefs is not portable, it is a collection of 2^n overlaid
> > programs, where n is the number of distinct #if[n]def tags. It's too bad
> > the problems of that approach were not appreciated by the C standard
> > committee, who mandated the #ifndef guard approach that I'm sure could
> > count as a provable billion dollar mistake, probably much more. The cost
> of
> > building #ifdef'ed code, especially with C++, which decided to be more
> > fine-grained about it, is unfathomable.
> >
> > Google alone might well count for many millions of dollars in wasted
> > compilation equipment. I remember giving a Plan 9 demo to someone soon
> > after I got to Google. None of the features of the system were of
> interest.
> > The thing that astounded my audience was the ability to build the kernel
> on
> > a P90 in 20 seconds or so, and the window system in under 3. At that
> time,
> > a build of a Google server would require hours on a large distcc cluster.
> >
> > I still shudder to think of it. It's worse now, of course, far worse, but
> > Google has far larger clusters to handle it and some improvement in
> > tooling. However, the #ifdefs persist.
> >
> >
> > Tom Cargill warned Bjarne about this around 1984, but the plea fell on
> deaf
> > ears.
> >
> > -rob
> >
> >
> > On Mon, Feb 28, 2022 at 12:07 PM Douglas McIlroy <
> > douglas.mcilroy@dartmouth.edu> wrote:
> >
> > > > The X11 tree was a heavily ifdef-ed.  And it needed to be, I don't
> have
> > > > an answer as to how you would reuse all that code on different
> hardware
> > > > in a better way.
> > >
> > > Plan 9 did it with #include. The name of the included file was the
> same for
> > > every architecture. Only the search path for include files changed.
> Done
> > > with
> > > care, this eliminates the typical upfront #ifdefs.that define constants
> > > and set
> > > flags.
> > >
> > > Other preprocessor conditionals can usually be replaced by a regular
> if,
> > > letting
> > > the compiler optimize away the unwanted alternative. This makes
> > > conditionals
> > > obey the scope rules of C.
> > >
> > > Doug
> > >
>
> --
> ---
> Larry McVoy                  lm at mcvoy.com
> http://www.mcvoy.com/lm
>

[-- Attachment #2: Type: text/html, Size: 9026 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-28  1:04 Douglas McIlroy
  2022-02-28  7:22 ` Rob Pike
@ 2022-02-28 18:18 ` Warner Losh
  1 sibling, 0 replies; 20+ messages in thread
From: Warner Losh @ 2022-02-28 18:18 UTC (permalink / raw)
  To: Douglas McIlroy; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]

On Sun, Feb 27, 2022 at 6:07 PM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

> > The X11 tree was a heavily ifdef-ed.  And it needed to be, I don't have
> > an answer as to how you would reuse all that code on different hardware
> > in a better way.
>
> Plan 9 did it with #include. The name of the included file was the same for
> every architecture. Only the search path for include files changed. Done
> with
> care, this eliminates the typical upfront #ifdefs.that define constants
> and set
> flags.
>

The qemu project does this, for the most part. It makes things a lot
easier, but
does take some getting used to to find the proper file to be included. It
helps
a lot to keep the twisty maze of #ifdefs down to a dull roar.

FreeBSD (and all the BSDs) has a similar philosophy. You define the page
size,
for example, of the target, and the rest of the system is written to that
abstraction
rather than having #ifdefs in a lot of places. NetBSD is much better about
keeping
the total number of #ifdefs out of MI code than FreeBSD. In both cases, most
of the #ifdefs are basically #ifdef __HAS_FUNKY_THING <do funky thing here>
#endif that are needed on a couple of architectures, though usually that
idiom
is expressed by a macro (that's empty for most platforms) or an inline
function.


> Other preprocessor conditionals can usually be replaced by a regular if,
> letting
> the compiler optimize away the unwanted alternative. This makes
> conditionals
> obey the scope rules of C.
>

As long as they are always defined... :) Though older gcc/clang compilers
get cranky
when they view the if expression as a tautology (warning about the idiom
rather than
encouraging it: stupid clang tricks).

Warner

[-- Attachment #2: Type: text/html, Size: 2437 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-28  7:22 ` Rob Pike
@ 2022-02-28 14:07   ` Larry McVoy
  2022-02-28 18:47     ` Dan Cross
  0 siblings, 1 reply; 20+ messages in thread
From: Larry McVoy @ 2022-02-28 14:07 UTC (permalink / raw)
  To: Rob Pike; +Cc: TUHS main list, Douglas McIlroy

So I'm curious, did Plan 9 run on a similar number of architectures and
support a similar number of graphics cards?

If it did that, nicely, then you have a great point, the X11 people
(and most of us) clearly missed a better way to do things.  If this is
the case, I'd like to understand how you did it because just including
different definitions doesn't begin to scratch the surface of what the
#ifdefs did in X11, there were tons in the actual code.

Maybe the constant system interface made all the difference, that 
could be.  

If it supported a much smaller number of targets, well, sure, it's
easier to be clean if you have a clean set of targets.

I remain grateful for the #ifdefs, I could make enough sense of it 
all to bring up X11 on every platform I worked on.  It wasn't pretty,
there was a ton of "I don't recognize this $WHATEVER, what happens if
I just #if 0 around the whole thing?  Wow, it compiles, lets see if
I get a window system.  Yep, I do.  Shrug."  That limited what I had
to understand to the much smaller subset of code I was actually
going to run, yeah, that set of #ifdefs was a mess but not such
a mess that I didn't get a working X11.

I'm not arguing that #ifdef is good, I'm just acknowledging it had
a lot of benefit to me, and _for me_, the cost was worth it in that
instance.  I could have X11 working in less than a day.

I do get your point about abstracting the interface differences away,
I actually hate #ifdefs in the code with a passion so in BitKeeper we
had all that stuff buried under the abstractions.  We made everything
look like Unix, even on Windows, except for fork().  I haven't called
fork() directly in close to 20 years, we picked up spawn() and made that
work everywhere.  The abstraction layer cuts down on the #ifdefs in the
code a LOT.

On Mon, Feb 28, 2022 at 06:22:28PM +1100, Rob Pike wrote:
> Plan 9 had the distinct advantage of a constant system interface at the
> source level. X11 did not, but it also made essentially no attempt to
> abstract it away, so the lines starting #ifdef often outnumbered the actual
> code. I couldn't make hide nor hair of it, and had no way to reliably test
> any change.
> 
> C with #ifdefs is not portable, it is a collection of 2^n overlaid
> programs, where n is the number of distinct #if[n]def tags. It's too bad
> the problems of that approach were not appreciated by the C standard
> committee, who mandated the #ifndef guard approach that I'm sure could
> count as a provable billion dollar mistake, probably much more. The cost of
> building #ifdef'ed code, especially with C++, which decided to be more
> fine-grained about it, is unfathomable.
> 
> Google alone might well count for many millions of dollars in wasted
> compilation equipment. I remember giving a Plan 9 demo to someone soon
> after I got to Google. None of the features of the system were of interest.
> The thing that astounded my audience was the ability to build the kernel on
> a P90 in 20 seconds or so, and the window system in under 3. At that time,
> a build of a Google server would require hours on a large distcc cluster.
> 
> I still shudder to think of it. It's worse now, of course, far worse, but
> Google has far larger clusters to handle it and some improvement in
> tooling. However, the #ifdefs persist.
> 
> 
> Tom Cargill warned Bjarne about this around 1984, but the plea fell on deaf
> ears.
> 
> -rob
> 
> 
> On Mon, Feb 28, 2022 at 12:07 PM Douglas McIlroy <
> douglas.mcilroy@dartmouth.edu> wrote:
> 
> > > The X11 tree was a heavily ifdef-ed.  And it needed to be, I don't have
> > > an answer as to how you would reuse all that code on different hardware
> > > in a better way.
> >
> > Plan 9 did it with #include. The name of the included file was the same for
> > every architecture. Only the search path for include files changed. Done
> > with
> > care, this eliminates the typical upfront #ifdefs.that define constants
> > and set
> > flags.
> >
> > Other preprocessor conditionals can usually be replaced by a regular if,
> > letting
> > the compiler optimize away the unwanted alternative. This makes
> > conditionals
> > obey the scope rules of C.
> >
> > Doug
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-28  1:04 Douglas McIlroy
@ 2022-02-28  7:22 ` Rob Pike
  2022-02-28 14:07   ` Larry McVoy
  2022-02-28 18:18 ` Warner Losh
  1 sibling, 1 reply; 20+ messages in thread
From: Rob Pike @ 2022-02-28  7:22 UTC (permalink / raw)
  To: Douglas McIlroy; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 2215 bytes --]

Plan 9 had the distinct advantage of a constant system interface at the
source level. X11 did not, but it also made essentially no attempt to
abstract it away, so the lines starting #ifdef often outnumbered the actual
code. I couldn't make hide nor hair of it, and had no way to reliably test
any change.

C with #ifdefs is not portable, it is a collection of 2^n overlaid
programs, where n is the number of distinct #if[n]def tags. It's too bad
the problems of that approach were not appreciated by the C standard
committee, who mandated the #ifndef guard approach that I'm sure could
count as a provable billion dollar mistake, probably much more. The cost of
building #ifdef'ed code, especially with C++, which decided to be more
fine-grained about it, is unfathomable.

Google alone might well count for many millions of dollars in wasted
compilation equipment. I remember giving a Plan 9 demo to someone soon
after I got to Google. None of the features of the system were of interest.
The thing that astounded my audience was the ability to build the kernel on
a P90 in 20 seconds or so, and the window system in under 3. At that time,
a build of a Google server would require hours on a large distcc cluster.

I still shudder to think of it. It's worse now, of course, far worse, but
Google has far larger clusters to handle it and some improvement in
tooling. However, the #ifdefs persist.


Tom Cargill warned Bjarne about this around 1984, but the plea fell on deaf
ears.

-rob


On Mon, Feb 28, 2022 at 12:07 PM Douglas McIlroy <
douglas.mcilroy@dartmouth.edu> wrote:

> > The X11 tree was a heavily ifdef-ed.  And it needed to be, I don't have
> > an answer as to how you would reuse all that code on different hardware
> > in a better way.
>
> Plan 9 did it with #include. The name of the included file was the same for
> every architecture. Only the search path for include files changed. Done
> with
> care, this eliminates the typical upfront #ifdefs.that define constants
> and set
> flags.
>
> Other preprocessor conditionals can usually be replaced by a regular if,
> letting
> the compiler optimize away the unwanted alternative. This makes
> conditionals
> obey the scope rules of C.
>
> Doug
>

[-- Attachment #2: Type: text/html, Size: 2720 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
@ 2022-02-28  1:04 Douglas McIlroy
  2022-02-28  7:22 ` Rob Pike
  2022-02-28 18:18 ` Warner Losh
  0 siblings, 2 replies; 20+ messages in thread
From: Douglas McIlroy @ 2022-02-28  1:04 UTC (permalink / raw)
  To: TUHS main list

> The X11 tree was a heavily ifdef-ed.  And it needed to be, I don't have
> an answer as to how you would reuse all that code on different hardware
> in a better way.

Plan 9 did it with #include. The name of the included file was the same for
every architecture. Only the search path for include files changed. Done with
care, this eliminates the typical upfront #ifdefs.that define constants and set
flags.

Other preprocessor conditionals can usually be replaced by a regular if, letting
the compiler optimize away the unwanted alternative. This makes conditionals
obey the scope rules of C.

Doug

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-26 21:45 Brian Walden
  2022-02-26 22:16 ` Rob Pike
@ 2022-02-27 20:32 ` Sven Mascheck
  1 sibling, 0 replies; 20+ messages in thread
From: Sven Mascheck @ 2022-02-27 20:32 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

On 26.02.2022 22:45, Brian Walden wrote:

> [...]  Sometimes you could find an early version of the
> Bourne shell in /bin/nsh (new shell) in v6.

The 7th edition release of the Bourne shell contains a
   char version[] = "\nVERSION sys137    DATE 1978 Nov 6 14:29:22\n" in msg.c
which was unfortunately not used, remained unchanged in descendants, and got removed with SVR2.

I often wondered about the versions bevore "sys137".  I thought they were just lost.
So Brian's remark got my attention. I haven't found anything in the 6th ed variants I found in TUHS UNIX Archive.

Does anybody know how to find a Bourne shell before 7th ed?

Thanks and Cheers
Sven

[-- Attachment #2: Type: text/html, Size: 960 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
@ 2022-02-27  7:48 Noel Chiappa
  0 siblings, 0 replies; 20+ messages in thread
From: Noel Chiappa @ 2022-02-27  7:48 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

   > From: Clem Cole

   > what I don't remember was it in v5

Your memory is going! :-) We discussed this recently (well, recently in _our_
timescale :-); it's built into in 'cc' in V5:

  https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/cc.c

see "expand(file)".

	Noel

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
  2022-02-26 21:45 Brian Walden
@ 2022-02-26 22:16 ` Rob Pike
  2022-02-27 20:32 ` Sven Mascheck
  1 sibling, 0 replies; 20+ messages in thread
From: Rob Pike @ 2022-02-26 22:16 UTC (permalink / raw)
  To: Brian Walden; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]

Terminal input, shells and so on were all rudimentary by modern standards
in v6. By v7 things had become more familiar to 21st century folks. But for
v6, although it was an advancement on many systems extant at the time
(although not all), the clunky nature of this generated a vast flurry of
hackery around terminal drivers and shells. It's a messy history.

For the record, our v5/v6 lab in Toronto had mostly paper terminals,
despite being a graphics lab, and one of them, the DECWriter, didn't even
have lower case. Be thankful for your current setup.

One example of the limitations: in v6 you could not pipe into a shell
script because the shell used the script itself as standard input. And the
argument list was limited to 512 bytes.*

But hey, in v1 there weren't even multipart path names.

-rob

* My first day at Google using Linux in 2002, I got "arg list too long"
with a modest glob pattern, and thought, what, have we forgotten about
dynamic memory allocation? Moving to a Unix system after a decade plus on
Plan 9 was a shock.

On Sun, Feb 27, 2022 at 8:48 AM Brian Walden <tuhs@cuzuco.com> wrote:

> 6th Edition used the Thompson shell as /bin/sh. I don't think it had
> those capabilities. Sometimes you could find an early version of the
> Bourne shell in /bin/nsh (new shell) in v6.
>
> The 7th Edition made the Bourne shell /bin/sh. And there sometimes
> you could find the Thompson shell in /bin/osh (old shell).
>
> Will Senn wrote:
> > Login commands question:
> >
> > I'm sure it's simple, but I can't figure it out. How do I get something
> > to run at login in v6? Right now, I use ed to create a file 'setprof'
> > that contains:
> >
> >     stty erase[space][backspace][return]
> >     stty nl0 cr0
> >
> > Then after logging in:
> >
> >     sh setprof
> >
> > It works, but, it is pretty clunky.
> >
> > stty question:
> >
> > So, I looked at stty.c and it looks like the following should work, if
> > the terminal is sending ^H for backspace:
> >
> >     #define BS0     0
> >     #define BS1     0100000
> >
> >     modes[]
> >     ...
> >              "bs0",
> >              BS0, BS1,
> >
> >              "bs1",
> >              BS1, BS1,
> >
> >
> > but:
> >
> >     stty bs0
> >     or
> >     stty bs1
> >
> > don't result in proper backspace handling..
> >
> > but:
> >
> >     stty[space][^h][return]
> >
> >
> > works...
> >
> > Thoughts?
>

[-- Attachment #2: Type: text/html, Size: 3231 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [TUHS] run commands at login in v6 and stty
@ 2022-02-26 21:45 Brian Walden
  2022-02-26 22:16 ` Rob Pike
  2022-02-27 20:32 ` Sven Mascheck
  0 siblings, 2 replies; 20+ messages in thread
From: Brian Walden @ 2022-02-26 21:45 UTC (permalink / raw)
  To: tuhs

6th Edition used the Thompson shell as /bin/sh. I don't think it had
those capabilities. Sometimes you could find an early version of the
Bourne shell in /bin/nsh (new shell) in v6.

The 7th Edition made the Bourne shell /bin/sh. And there sometimes
you could find the Thompson shell in /bin/osh (old shell).

Will Senn wrote:
> Login commands question:
>
> I'm sure it's simple, but I can't figure it out. How do I get something
> to run at login in v6? Right now, I use ed to create a file 'setprof'
> that contains:
>
>     stty erase[space][backspace][return]
>     stty nl0 cr0
>
> Then after logging in:
>
>     sh setprof
>
> It works, but, it is pretty clunky.
>
> stty question:
>
> So, I looked at stty.c and it looks like the following should work, if
> the terminal is sending ^H for backspace:
>
>     #define BS0     0
>     #define BS1     0100000
>
>     modes[]
>     ...
>              "bs0",
>              BS0, BS1,
>
>              "bs1",
>              BS1, BS1,
>
>
> but:
>
>     stty bs0
>     or
>     stty bs1
>
> don't result in proper backspace handling..
>
> but:
>
>     stty[space][^h][return]
>
>
> works...
>
> Thoughts?

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2022-02-28 21:27 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-26 20:39 [TUHS] run commands at login in v6 and stty Will Senn
2022-02-26 21:03 ` Michael Kjörling
2022-02-26 22:49 ` Clem Cole
2022-02-26 23:12   ` Rob Pike
2022-02-27  0:46     ` Clem Cole
2022-02-27 15:01     ` Larry McVoy
2022-02-27 17:10       ` Clem Cole
2022-02-26 21:45 Brian Walden
2022-02-26 22:16 ` Rob Pike
2022-02-27 20:32 ` Sven Mascheck
2022-02-27  7:48 Noel Chiappa
2022-02-28  1:04 Douglas McIlroy
2022-02-28  7:22 ` Rob Pike
2022-02-28 14:07   ` Larry McVoy
2022-02-28 18:47     ` Dan Cross
2022-02-28 19:25       ` Dan Cross
2022-02-28 21:25         ` markus schnalke
2022-02-28 19:26       ` Clem Cole
2022-02-28 20:03         ` Adam Thornton
2022-02-28 18:18 ` Warner Losh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).