Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!mit-eddie!uw-beaver!tektronix!tekcrl!terryl From: terryl@tekcrl.TEK.COM Newsgroups: comp.unix.questions Subject: Re: Why does this shell program run under csh???? Message-ID: <1742@tekcrl.TEK.COM> Date: Thu, 11-Jun-87 13:57:27 EDT Article-I.D.: tekcrl.1742 Posted: Thu Jun 11 13:57:27 1987 Date-Received: Sat, 20-Jun-87 12:58:49 EDT References: <7804@brl-adm.ARPA> Reply-To: terryl@tekcrl.tek.com Organization: Tektronix, Inc., Beaverton, OR. Lines: 73 I was going to stay out of this, but since everyone else is going to put their $0.02 in, so will I..... In article <7804@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: + + >It would have been laughable to expect people to change all their + >existing scripts just so some grad student from a western university + >could distinguish input meant for his program rather than one written + >by several PhD's at an eastern public utility research lab. So he did + >the next best thing, and proclaimed that his program wouldn't run + >anything unless the first character was an octothorp, and would defer + >to his better educated predecessors' program instead. + ... + > (Root Boy) Jim Cottrell + + It seems to be that Jim is being fast and loose with the better + education implies better programming paridigm here. Bourn shell works, + +I don't think there's any doubt which camp I stand in. I was being cute. + + and has fewer bugs than Csh does, but if you look at the sources, you + will discover that the thing is written in a poor excuse for Algol, + implemented with the C pre-processor. Also, memory is allocated by This is a real joke (no (-: here). Try running lint on the Bourne shell source. When we were porting things to a 68000-based system, the Bourne shell caused us MUCH more grief than both csh and vi put together. (The only real bug I can remember from either csh or vi, but can't remember which, was trying to read 1 character into a short variable; definitely not kosher on a big- endian machine such as the 68000). +So what? I commend the guy for doing things his own way instead of +merely going along with someone's poor excuse for syntax, namely the +`one statement if model'. Since this is not net.lang.c I won't +belabor the point. Whether you like or dislike this style is up to +you, but if anyone who has trouble with it should be ashamed. + + trying to access the new memory, then if a segmentation fault happens, + allocate by moving the break forward and trying again. Pretty poor + programming practice. + +I don't see why. By that argument, demand paging sucks too. And how +do you think user programs get new stack space allocated? Let's compare apples to apples, not apples to oranges. Trying to access memory outside of your current allocation is a bug, pure and simple (and one that was fairly well documented in V7; I don't have any experience with earlier versions). You wouldn't believe the kludges we had to put into the compiler and the kernel to support the Bourne style of memory management. Ditto that comment about "pretty poor programming practice". Luckily, we were able to get rid of those kludges when the 68010 came out. Demand paging is only valid for those systems whose hardware supports it; a 68000 by itself could not support demand pagaing (I'm not counting those systems that used a second 68000 to bring in the faulted page while the main processor was essentially halted until that page was brought in). As for the comment about how user programs get new space allocated, it is a valid one, though. That one was solved by our hardware memory management unit. My main complaint with the Bourne shell was that is relies on some pretty heavy assumptions about the processor (either implicitly or explicitly). The biggie is that if an instruction generates a memory reference that is currently outside the range of allowable addresses (i.e. what is termed a "bus fault or bus error" in Unix jargon), then that instruction can be magically restarted AFTER some user level code has executed. Yuck!!!!! Terry Laskodi of Tektronix