8.11 解释器文件
这种文件是文本文件，其起始行的形式是：
#！ pathname [optional- a rg u m e nt]
在惊叹号和pathname之间的空格是可任选的。最常见的是以下列行开始：
#！/bin/sh
pathname通常是个绝对路径名，对它不进行什么特殊的处理(不使用PAT H进行路径搜索)。对这种文件的识别是由内核作为exec系统调用处理的一部分来完成的。内核使调用exec函数的进程实际执行的文件并不是该解释器文件，而是在该解释器文件的第一行中pathname所指定的文件。一定要将解释器文件（文本文件，它以#！开头）和解释器（由该解释器文件第一行中的pathname指定）区分开来。
很多系统对解释器文件第一行有长度限制。这包括#！、pathname、可选参数以及空格数。
是否一定需要解释器文件呢?那也不完全如此。但是它们确实使用户得到效率方面的好处，其代价是内核的额外开销（因为内核需要识别解释器文件）。由于下述理由，解释器文件是有用的：
(1) 某些程序是用某种语言写的脚本，这一事实可以隐藏起来。例如，为了执行程序8 - 11，只需使用下列命令行：
awkexample optional- arguments
而并不需要知道该程序实际上是一个awk脚本，否则就要以下列方式执行该程序：
awk -f awkexample optional- arguments
(2) 解释器脚本在效率方面也提供了好处。再考虑一下前面的例子。仍旧隐藏该程序是一个awk脚本的事实，但是将其放在一个shell脚本中：
awk 'BEGIN {
for (i = 0; i < ARGC; i++)
printf "ARGV[%d] = %s\n", i, ARGV[i]
exit
}' $*
这种解决方法的问题是要求做更多的工作。首先， shell读此命令，然后试图execlp此文件名。因为shell脚本是一个可执行文件，但却不是机器可执行的，于是返回一个错误， execlp就认为该文件是一个shell脚本(它实际上就是这种文件)。然后执行/bin/sh，并以该shell脚本的路径名作为其参数。shell正确地执行我们的shell脚本，但是为了运行awk程序，它调用fork , exec和wait。用一个shell脚本代替解释器脚本需要更多的开销。
(3) 解释器脚本使我们可以使用除/bin/sh以外的其他shell来编写shell脚本。当execlp找到一个非机器可执行的可执行文件时，它总是调用/bin/sh来解释执行该文件。但是，用解释器脚本，则可编写成：
# ! / bin / csh
(在解释器文件中后随C shell脚本)
再一次，我们也可将此放在一个/bin/sh脚本中(然后由其调用C shell)，但是要有更多的开销。如果三个shell和awk没有用#作为注释符，则上面所说的都无效。