4.1c sh "not found" errors

[jim at mcvax.UUCP]

Yes, we get them too, and an easy fix is to put
	#!/bin/sh
at the beginning of shell scripts, then they always work. But the
problem lies elsewhere, and is in fact, a problem where a new process
after an `exec' seems to get a garbage environment. Why, I don't know.
It has caused all sorts of problems here with uucp and the line-printer
daemon to mention two.  We have had to change some programs to use
`execve' with a null environment pointer, exec's would RETURN with no
error set!

If you have a shell script, without the `#!/bin/sh' at the front,
then executing it exhibits random results, it looks like, depending
on whether one of the relevant inodes is in core or not.
I added a line in kern_process.c/execve() to ensure the stuff on the
stack was terminated properly (this was in all previous V7-derived
systems) as follows:

	(void) suword((caddr_t)ap, 0);
#ifdef MCVAX
	(void) suword((caddr_t)ucp, 0);
#endif MCVAX
	setregs();
bad:

and now such exec's which exhibited random failure before fail with
EBADF, rather than going on with a crippled process. 

The `rmdir' system call also exhibits strange behaviour by not
giving an error when it should, a simple program with rmdir("..")
gives no error the first time (if it does, do a couple of `sync's
and `cd's) then works O.K.

Sam Leffler told me that the code in the `do' loop in
sys_generic.c/rwip() does not handle u.u_error properly, but I have
now changed that to no effect. He also said that this problem does
not happen on 4.2.

So I am interested to know what gives here too. Still, I reckon we
can live with it for a month or so longer.

Jim McKie	....decvax!mcvax!jim
		...philabs!mcvax!jim