🚀 go-pugleaf

If you try to start csh in a directory that you can't do a pwd in (i.e. a
directory where getwd fails), csh silently fails to start.  Try this:

	cd /tmp
	mkdir x
	cd x
	chmod 0 .
	csh -c date

The usual place where this bug shows up is in su -- you're in a directory
that user X can't read and when you "su X" you find that you're still you
and not X.  I thought this problem had been fixed at some point, but it's
definitely in 4.3+NFS from Mt. Xinu and probably in UCB's 4.3 as well.

In sh.dir.c in dinit(), there's code:

	else {
		cp = getwd(path);
		if (cp == NULL) {
			(void) write(2, path, strlen(path));
			exit(1);
		}
	}

However, 2 isn't a valid file descriptor at this point (allegedly, 0-2 are
good only when didfds is non-zero and it's zero at this point).  My fix is:

	else {
		cp = getwd(path);
		if (cp == NULL) {
			strcat(path, " -- can't start new shell\n");
			(void) write(SHDIAG, path, strlen(path));
			exit(1);
		}
	}

Just s/2/SHDIAG/ is enough to get some output, but the error message -- the
return value from getwd -- doesn't end with a newline and "getwd: can't
stat ." might not be enough to alert a novice user to the problem.

					Bill Mitchell
					whm@arizona.edu
					{allegra,cmcl2,ihnp4,noao}!arizona!whm