[Z] Point commands and source COMMANDS IN SHELL

1. shell script execution Method

There are two ways to execute shell scripts. One is to generate a new shell and then execute the corresponding shell scripts. The other is to execute the shell in the current shell and no longer enable other shells.

To generate a new shell and then execute scripts, add the statement at the beginning of the scripts file :#! /Bin/sh. This is the general usage of script files (. Sh. In this way, the new sub-shell (new sub-process) is started, and then the command is executed under it.

Another method is the source command mentioned above. instead of creating a new shell, execute all the commands in the current shell. Source: The Source command is the dot (.) command. Enter man source in bash and find the explanation of the source command. You can see the explanation "read and execute commands from filename in the Current Shell environment and ...". It can be seen that the source command is to execute the commands in the parameter file in the current process, rather than starting another sub-process (or sub-shell ).

2 source and dot commands

The source command is a built-in command of BASH Shell, which comes from C shell.

Another method of writing the source command is the dot symbol. Its usage is the same as that of source, which comes from the Bourne shell.

The source command can force a script to immediately affect the current environment.

The source Command forces all commands in the script to ignore the file permissions.

The source command is usually used to re-execute the modified initialization file, such as. bash_profile and. profile.

The source command can affect the execution of the scriptParentShellAnd export can only affectChildShellEnvironment.

 

Example:

$ Source ~ /. Bashrc or: $ .~ /. Bashrc

After execution ~ /. The content in bashrc takes effect immediately.

 

The source command (from the C shell) is the built-in command of the bash shell. The dot command is a dot symbol (from the Bourne shell) which is another name of the source. Similarly, the variables set in the current script will also be used as the script environment. The source (or point) command is usually used to re-execute the modified initialization file, such as. bash_profile and. profile. For example, if you modify the editer and term variables in. bash_profile after Logging On, you can run the source command to re-execute the command in. bash_profile, instead of logging off and logging on again.

The function of the source command is to execute a script, so: source. sh. /. what is the difference between sh? For example, if you use export $ KKK = 111 In a script. /. SH: run the script. After the script is executed, run echo $ KKK and find that there is no value. If you use source to execute the script and then echo it, you will find that KKK is 111. Because of the call. /. sh to execute shell is run in a sub-shell, so after execution, the result is not reflected in the parent shell, but the source is different, it is executed in this shell, so we can see the results.

The source command is an internal shell command. It reads all command statements from the specified shell file and runs them in the current process. Therefore, when multiple shell processes (both parent and child processes or unrelated processes) share a set of variable values, you can define these variable assignment statements into a shell file, use the dot statement in the program that requires these variable values to reference this shell file, so as to share the variable values (modifications to these variable values only involve this shell file ). Note that the shell file cannot contain statements containing location parameters, that is, it cannot accept command line parameters such as $1 and $2.

As can be seen from the above, the point of command is equivalent to the # include in the C language. The following is an example.

Let's first write a simple shell script file named file1:

#! /Bin/bash

A = "hi"

Echo $

Let's first execute this shell script, open the terminal, and input:./File1

What is the result? You should have seen it too:

Bash:./file1: Permission denied

Why. Let's skip this. Let's take a look at the other result:

../File1(Note: There is a space between the two points, or it will become a directory of the upper level. If you are not too troublesome, you can also writeSource./file1The result is different from the previous one. As we wish, hi is output.

./File1, Direct execution, requiredStartShellProcessAnd you do not seem to have the permission yet (this is OK after you change it, and I will talk about it later), but it is different to use a command (note ,. /file the point here is the meaning of the current directory), the point command will be executed in the current shell. In addition, how can we change the file1 permission so that we can execute chmod + x file1 in a shell script?

Run./file1 again. Is it OK?

Let's look at another example. First, script file file1

#! /Bin/bash

A = "hi"

Script File file2 (in the same directory as file1)

#! /Bin/bash

./File1

Echo $

Remember to change the file1 permission, or ../file1 won't be executed. Run the command to check the result. Nothing, right. Let's change file2, and use our dot command this time.

#! /Bin/bash

../File1

Echo $

The results are different. This example should clarify the problem. If you do not need to run the command, another shell process will be started. When you start this process, it will establish its own process environment (for the time being, call it ), then, at the end of the process, the environment it created was also destroyed. In addition, the dot command is different. It will bring the content of the shell script in the dot command to the current shell process. In this program, it is variable.

 

You can also explain the following question:

Why can't I see the set command after I set the environment variable with export in the shell script and run the shell? However, if you use set to directly display the export environment variable in the terminal.

The content of a shell script test. Sh is:

#! /Bin/bash

Export AA = 123

When we run test. Sh, It is the shell where the current terminal is located, fork a sub-shell, and then execute test. Sh. After the execution is complete, return the shell where the terminal is located. To understand this, we can easily understand it. sh sets the AA environment variable. It takes effect only in the subshell generated by fork. The subshell can only inherit the environment variable of the parent shell, but cannot modify the environment variable of the parent shell, so test. after sh ends, the environment of the parent process is overwritten. So after test. Sh, we can't see the value of the environment variable AA by using the set command.

Is there any way to make the environment variables of the script still exist on the current terminal after the script is executed? Use source or. (DOT ). Explicitly tell shell not to fork to execute the script, but to execute it in the current shell, so that the environment variables can be saved.

[Supplement]

The difference between the source command and shell scripts is,

Source executes the command in the current bash environment, and scripts starts a sub-shell to execute the command. In this way, if you write the commands for setting environment variables (or alias) into scripts, it will only affect the sub-shell and cannot change the current bash. Therefore, through the file (command column) when setting environment variables, use the source command.

[Z] Point commands and source COMMANDS IN SHELL