whm@arizona.UUCP (02/24/87)
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