* 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-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-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 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 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 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 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 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 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 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-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
* 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 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
* [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 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 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
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-27 7:48 [TUHS] run commands at login in v6 and stty Noel Chiappa -- strict thread matches above, loose matches on Subject: below -- 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 2022-02-26 21:45 Brian Walden 2022-02-26 22:16 ` Rob Pike 2022-02-27 20:32 ` Sven Mascheck 2022-02-26 20:39 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
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).