Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site cornell.UUCP Path: utzoo!linus!genrad!mit-eddi!mit-vax!eagle!harpo!floyd!vax135!cornell!dean From: dean@cornell.UUCP Newsgroups: net.unix-wizards Subject: Re: 4.1c Cshell bug? (actually an exec bug) Message-ID: <4585@cornell.UUCP> Date: Fri, 10-Jun-83 13:07:25 EDT Article-I.D.: cornell.4585 Posted: Fri Jun 10 13:07:25 1983 Date-Received: Sat, 11-Jun-83 10:57:39 EDT Sender: dean@cornell.UUCP Organization: Cornell Computer Science Lines: 39 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@cornell