The difference between a point command in the shell and the source command
1 shell script Execution methods
There are two ways to execute shell scripts, one is to create a new shell, and then execute the corresponding shell scripts, one that executes under the current shell and no longer enables other shells.
The new way to create a shell and then execute scripts is to add a statement at the beginning of the scripts file: #!/bin/sh. The usual script file (. sh) is this usage. This method first enables the new Sub-shell (the new child process) and then executes the command under it.
Another way to do this is by the source command, which no longer produces a new shell, but executes all commands under the current shell. Source:source command Point (.) Command. Enter man source under Bash, find the source command interpreter, and you can see the explanation "Read and execute commands from filename in the current shell environment and ..." 。 As you can tell, the source command executes each command in the parameter file in the current process, not the other driver process (or Sub-shell).
2 Source and Point commands
- The source command is a built-in command of the Bash shell, which comes from C shell.
- Another notation for the source command is the point symbol, which is used in the same way as source, from the Bourne shell.
- The source command can force a script to immediately affect the current environment.
- The source command enforces all commands in the script and ignores the permissions of the file.
- The source command is typically used to re-execute a newly modified initialization file, such as. Bash_profile and. Profile, and so on.
- The source command can affect the environment of the parent shell that executes the script, and export can only affect the environment of its child shell.
Examples of Use methods:
$source ~/.BASHRC or: $. ~/.bashrc
The content in ~/.BASHRC after execution takes effect immediately.
The source command (from C Shell) is a built-in command of the bash shell. The point command, which is a dot symbol, is another name for source (from the Bourne shell). Similarly, the variables set in the current script will also be used as the scripting environment, and the source (or point) command is often useful for re-executing the newly modified initialization files, such as. Bash_profile and. Profile, and so on. For example, if you modify the Editer and term variables in. bash_profile After logging in, you can use the source command to re-execute the. bash_profile command without logging off and logging back in.
The function of the source command is to execute a script, then: The source a.sh executes directly./a.sh is different, for example, you export in a script $KKK = 111, if you use./a.sh executes the script, after execution, you run the Echo $KKK , found that there is no value, if you use source to execute, and then echo, you will find kkk=111. Because calling./a.sh to execute the shell is run in a child shell, the result is not reflected in the parent shell after execution, but the source is different and is executed in this shell, so you can see the result.
The source command is an internal command of the shell that reads all the command statements from the specified shell file and executes them in the current process. So when multiple shell processes (parent-child or unrelated processes can) share a set of variable values, you can define these variable assignment statements in a shell file, and use point statements to reference the shell file in programs that require these variable values. This allows for variable value sharing (modifications to these variable values only involve the shell file). Note, however, that this shell file cannot include statements that contain positional parameters, that is, you cannot accept command-line arguments such as $, $.
As can be seen from the above, the Point command is equivalent to the C language inside the # include. Below we will give an example.
Let's start by writing a simple shell script file named File1:
?
123 |
#! /bin/basha="hi"echo$a |
Let's go ahead and execute this shell script, open the terminal and typing:./file1
What the result is, you should see it too:
?
1 |
bash: ./file1: Permission denied |
Why is it. Let's just take a look at this, and another result:
. ./file1 (Note that there is a space between the two points, oh, or become the first directory, if you are not too troublesome, you can also write source./file1) The result of this is not the same as before, as we wish, the output of hi.
./file1, direct execution, requires another shell process, and you do not seem to have this permission (this change is OK, and later), and the Point command is different (note,./file the point here is the current directory meaning), the point command will be executed under the current shell. Add a little bit about how to change the permissions of File1, so that we can do it by Shell script:
?
Do it again./file1, is it OK?
Let's look at another example. First script file File1
?
Script file File2 (in the same directory as file1)
?
123 |
#! /bin/bash./file1echo$a |
Remember to change the authority of File1, or,/file1 will not be able to carry out. Take a look at the results. Nothing at all, is it. Let's change the file2, and we'll use our order, please.
?
123 |
#! /bin/bash. ./file1echo$a |
How did the result be different? This example should still be able to explain some of the problems. If a command is not used, the shell process will be started, and when this is initiated, it will create its own process environment (so call it), and then at the end of this, the environment it created is destroyed. And the command will be different, it will bring the command of the shell in the script so that the content into the current shell process, in this program, is the variable A.
Again, the following question can be explained:
Why does the shell script use export to set the environment variable, and when it finishes executing, it cannot be seen with the set command? But if you directly in the terminal export environment variable with set is seen.
The contents of a shell script test.sh are:
?
12 |
#!/bin/bashexportAA=123 |
When we execute the test.sh, the Shell Fork of the current terminal is a child shell and then executes the test.sh, and then returns to the shell where the terminal is located. Understand this, it is easy to understand, We set the AA environment variable in test.sh, which takes effect only in the fork-out shell, the child shell can inherit only the environment variables of the parent shell, not the environment variables of the parent shell, so the environment of the parent process is overwritten when the test.sh is finished. So after test.sh, we use the SET command to not see the value of the environment variable AA.
What can be done to make the environment variables of the script still exist for the current terminal after the script executes? With Sorcue or. (dot). Explicitly tell the shell not to fork the script, but to execute it in the current shell so that the environment variables can be saved.
The difference between the source command and the shell scripts is:
Source executes the command in the current bash environment, and scripts starts a child shell to execute the command. This way, if the command to set the environment variable (or alias, etc.) is written into scripts, it will only affect the child shell and cannot change the current bash, so use the source command when setting the environment variable through the file (command column).
Transferred from: http://blog.chinaunix.net/uid-22028566-id-3182362.html
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
The difference between a point command in the shell and the source command