难得找到的一点关于解释器的内容

原文地址：http://shaoguangleo.blog.163.com/blog/static/227798320119228330392/

原文标题：8.11 解释器文件

     前言：这篇文章有点罗索，但总的来说，它说明了解释性语言编写的解释性程序的一个共同点，程序本身不是pe文件（windows上）这样的二进制码文件，不是机器直接可执行的，操作系统在识别此文件后，会调用相应的脚本解析器进行解释执行．通常是一句一句的解析，解析出一句可执行语句后，就执行调用内核系统调用执行相应操作．例如，一段bash脚本分为三句，第一句，新建一个文本文件，第二句，向其中写入字符串，第三句，关闭文件．解析器解析过程中，遇到第一句，会执行转换成内核调用，调用相应的内核调用接口完成新建文件操作．遇到第二句，仍用相应的内核调用接口完成文件写操作．第三句同理．

下面是原文的内容：

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

这种文件是文本文件，其起始行的形式是：

#！ pathname [optional- a rg u m e nt]

在惊叹号和pathname之间的空格是可任选的。最常见的是以下列行开始：

#！/bin/sh

pathname通常是个绝对路径名，对它不进行什么特殊的处理(不使用PAT H进行路径搜索)。对这种文件的识别是由内核作为exec系统调用处理的一部分来完成的。内核使调用exec函数的进程实际执行的文件并不是该解释器文件，而是在该解释器文件的第一行中pathname所指定的文件。

一定要将解释器文件（文本文件，它以#！开头）和解释器（由该解释器文件第一行中的pathname指定）区分开来。

很多系统对解释器文件第一行有长度限制。这包括#！、pathname、可选参数以及空格数。

是否一定需要解释器文件呢?那也不完全如此。但是它们确实使用户得到效率方面的好处，其代价是内核的额外开销（因为内核需要识别解释器文件）。

(1) 某些程序是用某种语言写的脚本，这一事实可以隐藏起来。例如，下列命令行：

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)，但是要有更多的开销。