Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!jsq From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) Newsgroups: comp.std.unix Subject: "#!" magic number (was: Shell standardization) Message-ID: <17650@cs.utexas.edu> Date: 4 Feb 91 11:50:07 GMT References: <17011@cs.utexas.edu> <17065@cs.utexas.edu> <17155@cs.utexas.edu> Sender: jsq@cs.utexas.edu Organization: NCR Microelectronics, Ft. Collins, CO Lines: 33 Approved: jsq@cs.utexas.edu (Moderator, John S. Quarterman) X-Submissions: std-unix@uunet.uu.net Submitted-by: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) >>>>> On 22 Jan 91 21:28:49 GMT, guy@auspex.uucp (Guy Harris) said: Guy> I don't strongly care where it's done (although I *do* prefer having Guy> "execl()" AND "execv()" capable of running scripts, even if it's done by Guy> having them be wrappers around kernel traps with the wrappers checking Guy> for the "#!" line if they get ENOEXEC), but it *would* be nice if the Guy> system didn't inappropriately try to run files that happened to have Guy> execute permissions as scripts if, in fact, they aren't scripts. Essentially, "#!" becomes a magic number. I would also prefer this be in the kernal. Invitation for discussion: If the path after the "#!" doesn't begin with "/", "./" or "../", should PATH be searched for the execuatble? If so, how best could this be implemented? The reason I bring this up is in SVr4 (OSF/1?), there have been changes in the directory hierarchy and commands are not necessarily where they've historically been. Of course, all scripts that are part of the OS can (and should!) contain absolute path names. It would be nice for application developers to be able to write hierarchy independent scripts. Even nicer would be for applications developers to be able to write their own interpreters without caring where the user installs the interpreter (as long as the interpreter's directory is in PATH). -- Chuck Phillips MS440 NCR Microelectronics chuck.phillips%ftcollins.ncr.com 2001 Danfield Ct. Ft. Collins, CO. 80525 ...uunet!ncrlnk!ncr-mpd!bach!chuckp Volume-Number: Volume 22, Number 107