8.11 解释器文件

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] = %sn”, i, ARGV[i]

exit

}’ $*

这种解决方法的问题是要求做更多的工作。首先, shell读此命令,然后试图execlp此文件名。因为shell脚本是一个可执行文件,但却不是机器可执行的,于是返回一个错误, execlp就认为该文件是一个shell脚本(它实际上就是这种文件)。然后执行/bin/sh,并以该shell脚本的路径名作为其参数。shell正确地执行我们的shell脚本,但是为了运行awk程序,它调用fork , execwait。用一个shell脚本代替解释器脚本需要更多的开销。

(3) 解释器脚本使我们可以使用除/bin/sh以外的其他shell来编写shell脚本。当execlp找到一个非机器可执行的可执行文件时,它总是调用/bin/sh来解释执行该文件。但是,用解释器脚本,则可编写成:

# ! / bin / csh

(在解释器文件中后随C shell脚本)

再一次,我们也可将此放在一个/bin/sh脚本中(然后由其调用C shell),但是要有更多的开销。如果三个shellawk没有用#作为注释符,则上面所说的都无效。