Linux Interpreter principle Detailed Introduction __linux

Introduction to Shell programming: The Linux Interpreter principle details November 22, 2007 Thursday 10:32

People who work with the shell are familiar with Shell programming under Unix/linux, and in all of the shell-programming books, #!/bin/bash is mentioned, and what is in it. What this line of string means for the operating system. You might say, not just let the/bin/bash program explain the script. Of course you're right, look at our title, here we talk about the interpreter, let's look at what the first sentence in the script file means to the system. But one thing we can make clear is that the interpreter is the executable program that follows the #! line. First, we start with the Exec family function If you never write a C program, you may need to look more closely at the contents of this section and experiment. Code: Quote: #include extern char **environ; int execl (const char *path, const char *arg, ...); int EXECLP (const char *file, const char *arg, ...); int execle (const char *path, const char *arg, ..., char * const envp[]); int execv (const char *path, char *const argv[]); int EXECVP (const char *file, char *const argv[]); The Exec family function is a total of 5 listed above, and the function is the same: execute a new piece of code. The difference is only in the way the parameters are passed to the function. I'm here to talk about the EXECL function: the first parameter path is the path that sets the execution bit file, followed by the variable argument list, which points to the list of parameters passed to the execution file (including parameter 0, the name of the execution file). The last parameter is (char *) 0, which indicates the end of the argument list. For the interpreter, the Exec family function does this (in Execl, for example), if path is pointing to a script, the first line of the script begins with #!, then this is called: A new program execution is formed by following the #! string as a command followed by the list of parameters specified in the Execl argument list. Here's an example to verify the result: The function of the C program below is to echo all command-line arguments. Code: 　 QUOTE: /* Program SOURCE:SHOWARGS.C * * Program Name:showargs * * #include Int Main (int argc, char *argv[]) { int i; for (i = 0; i); } return 0; } Compiling: Gcc-o Showargs showargs.c Perform: Code: 　 QUOTE: $ pwd /home/kiron $./showargs arg1 arg2 Arg[0]:./showargs ARG[1]: arg1 ARG[2]: arg2 We write a script in the same directory: Code: 　 QUOTE: #!/home/kiron/showargs Addargs I didn't make a mistake, yes, this script is just one line, English code This script we name as testexec, plus execution bit after the execution is as follows: Code: QUOTE: $./testexec Arg[0]:/home/kiron/showargs ARG[1]: Addargs ARG[2]:./testexec How could this be. I guess someone will be on the 2nd argument./testexec do not understand, to sell a few, and then lead to a C program: Code: 　 QUOTE: /* Program SOURCE:MYTEST.C * * Program Name:mytest * * #include Int Main (void) { Execl ("/home/kiron/testexec", "Testexec", "Arg1", "Arg2", (char *) 0); return 0; Compile: Gcc-o mytest mytest.c Perform: Code: $./mytest Arg[0]:/home/kiron/showargs ARG[1]: Addargs ARG[2]:/home/kiron/testexec ARG[3]: arg1 ARG[4]: arg2 With a careful look at the three examples above, the answer begins to surface. As mentioned at the outset, the Exec family function handles the #! string as a command followed by a list of parameters specified in the Execl argument list, which creates a new program execution. Analysis of the MYTEST.C source program, execl the result of the command is to perform the/home/kiron/testexec content is #!/home/kiron/showargs Addargs, then #! the string "/home/kiron/ Showargs Addargs "plus a list of command arguments:"/home/kiron/testexec arg1 arg2 "creates a new program line:/home/kiron/showargs addargs/home/kiron/ Testexec arg1 arg2. For the testexec script, when we call it in the shell, the shell invokes fork,exec,wait to execute it, that is, the EXEC function is used like the program mytest.c, first of all, the EXEC function interprets the #! row and then the interpreter for this script is/home /kiron/showargs, and then it was formed to handle the command line: "/home/kiron/showargs Addargs./testexec". Note: The path to the interpreter in the #! line must be a full path, and the EXEC function does not specifically deal with it, such as using the path variable to search for its true path, so the path is guaranteed by the programmer. second, my script must be #!/bin/bash the first sentence. Of course not, through the above explanation, in fact, the first sentence of the #! is the Interpreter program path to the script, the content of the script is explained by the interpreter, we can use a variety of interpreters to write the corresponding script, such as/bin/csh script,/bin/perl script,/bin/awk script,/ bin/sed scripts, even/bin/echo and so on. So can we really write a/bin/echo script file? Let's try it, here's an example: Code: #!/bin/echo-e I have only one line of program (in fact, it can only be a line, the Echo program is not designed as a programming language like awk, can be written as a source program file) named Myecho, plus permissions to execute it: Code: $./myecho "hi/a" ./myecho Hi If your echo supports the-e option and your work environment is quiet, you should also hear the crisp terminal bells when you get the results above. But this procedure is of no effect. Three, I can use the interpreter to do what. But the above echo script does not work in practice, and we can come up with a small experimental result, not all executable binaries can be used to write interpreter scripts. So what's the use of my script to write an interpreter? If you have a programmable interpreter, you may be able to write the interpreter's program to simplify your work. For example, commonly used interpreters such as Awk,perl,bash and so on. But as the results of the experiment we summarized above, unfortunately, not all programmable programs are useful interpreters, the exec script can get a script interpreter from the first line, and then use exec to interpret the script (which may be the option to control, such as #!/bin/awk-f), including the form #!/ Path/'s first line, if the interpreter can not ignore this line, there will be errors, and the interpreter must be able to explain the rest of the program (this sentence seems to be nonsense, but imagine, the above Myecho program plus some "Hello World" line, will be effective. The same is true of s/unix/unix/p in the following mysed program. A program like Awk,perl,bash can write useful scripts when it is commented line processing. Then look at the following mysed program. Code: Quote: #!/bin/sed-f An error occurred while s/unix/unix/p execution./mysed. Because it was interpreted as "/bin/sed-f./mysed", where the-f option was to represent a command input with the contents of the document as SED, but the command input of SED could not explain "#!/bin/sed-f", then the program went wrong. Therefore, the useful interpreter should be similar to the Bash,perl,awk program, and can have some explanatory function to the specified statement. The following is a script that myawk the number of rows and number of words in the awk program. Code: 　 #!/usr/bin/awk-f BEGIN { sum = 0; } {sum = NF;} End { printf ("File/"%s/"have%d line,%d words./n", FILENAME, NR, sum); After setting the execution bit, do the following: Code: $ ECHO-E "Hi/nhello World" >test.txt $./myawk Test.txt File "Test.txt" Have 2 line, 3 words Execute here./myawk is executed as "/usr/bin/awk-f./myawk test.txt" Because the line at the beginning of the awk command is considered to be a comment line and ignored, Awk ignores the first line of "#!/usr/bin/awk-f", and the correct one is not # The beginning line is the input of the pattern and the command and can be interpreted, so the program is correct and can be executed smoothly.