rusty@sdcarl.UUCP (06/08/83)
i'm not sure if this is a bug, it seems to me that it is. if you run the following shell script: #! /bin/sh sleep 9600 & echo sleeping... sleep 3600 then after you get the "sleeping..." message you do a ^Z, if you do a ps you will discover that both sleeps have been stopped. i would expect that only the 2nd one would be stopped. this happens regardless of whether the first line in the shell script is "#! /bin/sh" or "#! /bin/csh".
joe@cvl.UUCP (06/13/83)
Rusty@sdcarl wanted to know of the behaviour of the script #! /bin/sh sleep 9600 & echo sleeping... sleep 3600 was wrong, because it showed both sleep processes stopped after being ^Z'ed (started from a csh, of course). The answer to the question is no, there is nothing wrong about this behaviour, even when the first line specifies /bin/csh instead of /bin/sh. I've seen a number of people make a similar subtle assumption about '&'. The problem is that people who've been exposed to the csh first do not realize the csh explicitly manipulates the process group of every subprocess. The two most common mistakes are (1) to assume that sh does the same thing, and (2) to assume that NONINTERACTIVE instances of csh still manipulate process groups. A stop signal from the terminal is dispatched to all members of the terminal's current process group. For the regular shell, and noninteractive c-shells, this means all of the shell's children are in the same process group as the shell itself, and all will receive the signal (if the shell itself is in the terminal's pgrp, which it will be if started from sh or an interactive csh). The reason I'm familiar with all this is that we have some users running the standard shell (for historical reasons). Unfortunately, they'd been told by well-meaning csh users that `nohup' was not necessary under Berkeley UNIX when processes were started with '&'. Of course, the moment they logged out their background processes got a SIGHUP, since they were in the terminal's process group. It's trivial to write a command I call `newpg', which simply executes its arguments as a command in a new process group. Hence, 'newpg command args ... & ' behaves under sh and noninteractive csh like the corresponding 'command args ... & ' does in an interactive csh. joe@cvl.uucp seismo! mcnc!rlgvax!cvl!joe we13!
alt@aids-unix@sri-unix.UUCP (09/01/83)
From: Howard Alt <alt@aids-unix> Has anyone seen the following problem: set i = 2 set i1 = 2 @ i = $i + $i @ i1 = $i1 + $i1 The last line reports '@: Syntax error'. In the manual, it says that variables are allowed to be up to 20 numbers or letters as long as it starts with a letter. Incidently, the line @ i = $i1 + $i1 works fine. It seems that any variable with a number in it, gives this same problem. Any csh hackers out there seen this problem? Thanks, Howard.
ptw@vaxine.UUCP (P. T. Withington) (05/03/84)
We have recently purchased a number of Venix's and noticed that their csh
seems to grow ad nauseum, eventually blowing out its (small/medium model) data
segment. Thought this was just a bad port on Venturcom's part, but seem to
see the same effect on our Vaxen (of course the data segment there has yet
to blow out...). Has anyone else noticed this bug/feature? No we don't have
our history set to infinity.
Additional detail: it almost looks like csh is just never freeing anything.
One quick way to blow out our Venix is to source a .cshrc full of aliases
a couple of times in a row. I do recall that csh does some funny mumbo-jumbo
in place of malloc/free...
o.o -ptw
~mats@dual.UUCP (Mats Wichmann) (05/07/84)
Our copy of CSH has never seemed to show this behavior - perhaps somebody over at UniSoft might enlighten us as to the nature of the problem, since they seem to have fixed it. On the other hand, maybe not - they may have a competitive advantage here. How `bout it, guys?
olson@fortune.UUCP (05/08/84)
#R:vaxine:-25300:fortune:11600094:000:760
fortune!olson May 7 18:25:00 1984
The csh (at least the 4.1 csh) does use malloc and free to do memory
allocation. (In fact, it does more malloc'ing and free'ing than any
other program I've seen!)
It is possible that during the port someone messed up
on signal handling, so that things are left in a strange state after
an interrupt. It is also possible that some kind of error was
introduced to the malloc/free/realloc code that only shows up under
intensive use.
If the person(s) doing the port made modifications to the csh, they
could have introduced some errors; malloc/free are very unforgiving
of errors (particularly those involving freeing memory not allocated
by malloc).
Dave Olson, Fortune Systems
UUCP: {ihnp4,ucbvax!amd70}!fortune!olson
ARPA: amd70!fortune!olson@BERKELEYesa@kvvax4.UUCP (Esa K Viitala) (05/10/84)
>>We have recently purchased a number of Venix's and noticed that their csh >>seems to grow ad nauseum, eventually blowing out its (small/medium model) data >>segment. Thought this was just a bad port on Venturcom's part...... >The same thing seems to happen under xenix's csh, I have no reason why, >but when it runs out of space, it is not handled very gracefully.... >(i.e., core dump time) Here too, I think. We have 4.1bsd/vax11/780, and occasionally csh says 'assertion botched <something or other>' and then nothing. This comes from a memory allocation routine, I forgot the name, if either the chain of blocks has corrupted or the the chain is empty. I've concluded that it ain't corrupted. Fixes anybody? -- Esa K Viitala {decvax,philabs}!mcvax!kvport!kvvax4!esa A/S Kongsberg Vaapenfabrikk,CTG4,P.O.Box 25,N-3601 Kongsberg,Norway tel. 473-739644 tlx. 71491 vaapn n
kds@intelca.UUCP (Ken Shoemaker) (05/13/84)
>We have recently purchased a number of Venix's and noticed that their csh >seems to grow ad nauseum, eventually blowing out its (small/medium model) data >segment. Thought this was just a bad port on Venturcom's part...... The same thing seems to happen under xenix's csh, I have no reason why, but when it runs out of space, it is not handled very gracefully.... (i.e., core dump time) -- Ken Shoemaker, Intel, Santa Clara, Ca. {pur-ee,hplabs,ucbvax!amd70,ogcvax!omsvax}!intelca!kds