Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!bronze!cica!travis!greg From: greg@travis.cica.indiana.edu (Gregory TRAVIS) Newsgroups: comp.sys.amiga.advocacy Subject: Re: How to improve Workbench 2.0! Message-ID: Date: 13 Feb 91 00:18:09 GMT References: <1991Feb11.113601.1338@sugar.hackercorp.com> <9474@uwm.edu> <7553@jhunix.HCF.JHU.EDU> Sender: news@cica.indiana.edu (News System) Organization: Indiana University Lines: 25 Nntp-Posting-Host: travis.cica.indiana.edu barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes: > Peter is making a good point. On UNIX, there is only 1 bit for this >(execute). If the file is a text file, it is automatically fed to an >interpreter program. By default, the interpreter is the shell (specifically >the Bourne Shell), but you can make it ANY interprer by specifying the name >of the interpreter as the first line of the file. Just want to clarify the mechanism by which a file is determined to be a script under UNIX: The shell first tries to "exec" the file - meaning it hands it to the Kernel for execution as a binary file without ever looking at it. The Kernel then reads the header and if it doesn't find a magic number in the header that indicates the file is executable it returns on the exec and sets an error. The shell then says "Hmm, maybe it's a script" and reads it (looking for that #! /bin/xxx if it's in there). Some (most) Kernels incorporate a (aesthetically horrible) efficiency hack in that the Kernel looks for the "#!" characters and, if it finds them, executes the named shell with the script filename as argument instead of just failing the exec. -- Gregory R. Travis Indiana University, Bloomington IN 47405 greg@cica.indiana.edu Center for Innovative Computer Applications This signature intentionally left blank.