moss%brl-vld@sri-unix.UUCP (06/08/83)
From: Gary S. Moss X-6647 <moss@brl-vld> When I try an "apropos foo" from the Cshell, about 2 times out of 10 it comes back with "/usr/ucb/apropos: Bad file number", indicating mass confusion on somebody's part. More rarely it says "apropos: command not found" when it's clearly there and on the path. What's going on? You need to do two things: 1) Alias all of your private stuff by absolute path name (i.e. alias foo /usr/name/bin/foo). This should get around the "not found" messages which are a result of a bug in 4.1c. 2) Put #!/bin/csh as the first line of all your Cshell scripts. This will eliminate the "Bad file number" messages. - Moss.
Michael.Young%cmu-cs-a@sri-unix.UUCP (06/08/83)
From: Michael Wayne Young <Michael.Young@cmu-cs-a> Your problem with apropos is particularly surprising to me. The apropos here (4.1a, which is probably the same) just runs 'man' with a '-k' option, and is only a shell command file. [Does the Bourne shell do the same thing? It seems that it'd be a shell problem.] Anyway, the other point is that 'man' doesn't look for things in your path -- just in the manual. Also, 'whereis' just looks in common places. [I've written my own 'whereis'-like program for just this reason... it particularly helps since the shell doesn't allow you to "dump" the command name hash table to see where your commands come from.] Michael
dean@cornell.UUCP (06/10/83)
There is a bug in the exec routine in the 4.1c kernel. One
manifestation of this bug is when the shell tries to execute a command
file that does not have "#! /bin/csh" (or "#! /bin/sh") as its first
line. The problem is that an incorrect error code is sometimes
returned, resulting in messages like "Bad file number".
There are two ways (at least) to fix this problem. One is to make sure
that there is always an explicit shell specification at the beginning
of shell command files. In this case the exec will always succeed, and
the shell program won't have to look at the returned error code. The
other fix is to install the following code into /sys/sys/kern_process.c
and build and install a new system. The code replaces that at the end
of the "execve" function from the label "bad:" to the end of the function.
-----------------------------------------------
bad:
/* CORNELL DEBUG: claim there's a path */
/* thru iput that clears u.u_error. */
{ int sav_u_error;
sav_u_error = u.u_error;
u.u_error = 0;
if (bp)
brelse(bp);
if (bno)
rmfree(argmap, (long)ctod(clrnd((int) btoc(NCARGS))), bno);
iput(ip);
if( u.u_error == 0 )
u.u_error = sav_u_error;
}
}
-----------------------------------------------
Berkeley is aware of the problem, and it will presumably be fixed in
later releases.
Dean Krafft
Cornell Computer Science Dept.
(607) 256-4052
uucp: decvax!cornell!dean
ARPA: dean@cornellshannon@sun.UUCP (06/10/83)
The "Bad file number" problem in the csh on 4.1c is not specific to apropos or the csh. The problem is a kernel bug which I fixed a while ago but it may not have made it in all 4.1c tapes. The fix is in biowait in ufs_bio.c; change u.u_error = geterror(bp); to if (u.u_error == 0) u.u_error = geterror(bp); Bill Shannon Sun Microsystems Inc.
mike.rice@rand-relay@sri-unix.UUCP (06/14/83)
From: Mike.Caplinger <mike.rice@rand-relay> I hope that it's OK to talk about 4.1c these days; I understand we're one of the last sites in the country to get it, so the rest of you should have had enough time to get knowledgable. When I try an "apropos foo" from the Cshell, about 2 times out of 10 it comes back with "/usr/ucb/apropos: Bad file number", indicating mass confusion on somebody's part. More rarely it says "apropos: command not found" when it's clearly there and on the path. What's going on?