The role of Linux export

Feature Description: Sets or displays environment variables. Syntax: Export [-fnp][variable name]=[variable setting value] Additional note: When executing a program in the shell, the shell provides a set of environment variables. Export can add, modify, or delete environment variables for use by subsequent executing programs. The effect of export only extends to the operation of this landing. Parameters -F represents the function name in [variable name]. -n Deletes the specified variable. The variables are not actually deleted, but are not exported to the execution environment of the subsequent directives. -p lists all the environment variables that the shell assigns to the program.

Shell and Export commands

After the user logs on to the Linux system, a user shell is launched. In this shell, you can use a shell command or declare a variable, or you can create and run a shell script program. When you run a shell script, the system creates a child shell. At this point, there will be two shells in the system, one for the system-initiated shell at logon, and the other for the shell created by the system to run the script. When a script is finished running, its script shell terminates and can be returned to the shell before the script executes. In this sense, a user can have many shells, each of which is derived from a shell, called the parent shell.

A variable defined in a child shell is valid only within that child shell. If a variable is defined in a shell script, when the script is run, the defined variable is only a local variable within the script, and the other shell cannot reference it, so that the value of one variable can be changed in the other shell. You can use the Export command to output a defined variable. The export command will allow the system to define a copy of this variable when creating each new shell. This process is called variable output.

[Example] In this example, the variable myfile is defined in the Dispfile script program. The Export command is then used to output the variable myfile to any child shell, such as the child shell that is produced when the Printfile script is executed.

Dispfile Script Program Checklist:

/**************begin dispfile**************/

Myfile= "List"

Export MyFile

echo "Displaying $myfile"

Pr–t–n $myfile

Printfile

/**************end dispfile***************/

　

Printfile Script Program Checklist:

/**************begin printfile**************/

echo "Printing $myfile"

LPR $myfile &

/**************end printfile**************/

$dispfile

Displaying List

1 screen

2 Modem

3 paper

Printing List

$

Linux Instructions: System setup--export

Feature Description: Sets or displays environment variables.

syntax:export [-fnp][variable name]=[variable setting value]

Additional Note: when executing a program in the shell, the shell provides a set of environment variables. Export can add, modify, or delete environment variables for use by subsequent executing programs. The effect of export only extends to the operation of this landing.

Parameters
-F represents the function name in [variable name].
-n Deletes the specified variable. The variables are not actually deleted, but are not exported to the execution environment of the subsequent directives.
-p lists all the environment variables that the shell assigns to the program.

Http://linux.chinaitlab.com/command/723900.html

Shell environment and variable lifetimes understood from the Learning Export command

I am also a rookie, I have not been in contact with Linux for a long time, recently in Learning Bash's Export command encountered a (the book says export is to change the custom variable into a system environment variable): I define a variable in a script file, and then export the variable, According to my own idea, after executing this script, at the prompt will be able to use Echo to display its value, but the result is not so, the script after the execution of the set does not see the existence of this variable. Why is it? I can not think of its solution, finally put the issue, a predecessor told me to say with source+ script file on it, I tried it really can, but a new problem came out again. After I delete the export command in my script, I can use source as well. There seems to be no use in this export.

After many attempts to find something, I guess, if there is something wrong, please correct me, thank you.

When executing a script, a child shell environment is opened (not knowing that other programs are executing), and then all the system environment variables in the parent shell are copied, and the statements in the script are executed in the child shell. (That is, the environment variable of the parent shell can be called in the child shell, but not the other way, if the environment variable is defined in the child shell, only the shell or its child shell is valid, when the child shell ends, it can also be understood that the variable disappears when the script finishes executing.) To prove this, look at the script content:

test= ' value '

Export Test

When such a script finishes executing, test does not actually exist. Then look at the following:

test= ' value '

Export Test

Bash

Here in the last line of the script to open a child shell, the shell should be the shell of the script file is the child shell, after the script is executed, you can see the test variable, because now is in its child shell, when exit child shell with exit, The test variable disappears.

If you execute the script with source, you will not see this variable in the child shell if you do not add the export, because it is not a system environment variable, such as the script content is:

test= ' value '

After executing with source, you can see this variable under the shell, but when you execute bash to open a child shell, test is not copied to the child shell, because the execution script file is actually run in a child shell, so when I build another script file to execute, Will not enter anything, such as: Echo $test. So this particular attention, obviously at the prompt can use echo $test output variable value, why put it into the script file is not?

So the conclusion is: 1, the script is executed in a child shell environment run, the script after the execution of the child shell automatically exit, 2, a shell of the system environment variables will be copied to the child shell (the variable defined by export); 3, A system environment variable in a shell is valid only for the shell or its child shell, and the shell ends when the variable disappears (and cannot be returned to the parent shell). 3. Variables defined without export are valid only for the shell, and the child shell is not valid.

Later, according to the moderator's tips, organized a few posts: why a script directly executed and with the source to execute a line? This is also a problem I have encountered. Manual Original Is this: Read and execute commands from filename in the current shell environment and return the exit status of the LA St command executed from filename. You understand why it's not the same? Executing a script file directly is run in a child shell, while source is running in the current shell environment. According to the previous content, you have already understood the truth of it.

The problem that bothered me for a few days can finally be solved satisfactorily.

How to set environment variables in Linux (export PATH)

In general, you need to specify the path of the compilation tool when configuring the cross-compilation tool chain, and you need to set the environment variables. For example, my MIPS-LINUX-GCC compiler is in the "/opt/au1200_rm/build_tools/bin "directory, Build_tools is my compilation tool, there are three ways to set environment variables:

1. Direct with export command:
#export path= $PATH:/opt/au1200_rm/build_tools/bin
To see if it is already set up, use the command export to view:
[Email protected] bin]#Export
Declare-x bash_env= "/ROOT/.BASHRC"
Declare-x g_broken_filenames= "1"
Declare-x histsize= "1000"
Declare-x home= "/root"
Declare-x hostname= "Localhost.localdomain"
Declare-x inputrc= "/ETC/INPUTRC"
Declare-x lang= "ZH_CN. GB18030 "
Declare-x language= "Zh_CN.GB18030:zh_CN.GB2312:zh_CN"
Declare-x lessopen= "|/usr/bin/lesspipe.sh%s"
Declare-x logname= "Root"
Declare-x ls_colors= "no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi= 01;05;37;41:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.sh=01;32:*.csh=01;32:*.tar= 01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*. Z=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tz=01;31:*.rpm=01;31:*.cpio=01;31:*.jpg=01;35:*.gif=01;35:*.bmp=01 ; 35:*.xbm=01;35:*.xpm=01;35:*.png=01;35:*.tif=01;35: "
Declare-x mail= "/var/spool/mail/root"
Declare-x oldpwd= "/opt/au1200_rm/build_tools"
Declare-x path= "/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/x11r6/bin:/root/bin:/opt/ Au1200_rm/build_tools/bin "
Declare-x pwd= "/opt/au1200_rm/build_tools/bin"
Declare-x shell= "/bin/bash"
Declare-x shlvl= "1"
Declare-x ssh_askpass= "/usr/libexec/openssh/gnome-ssh-askpass"
Declare-x ssh_auth_sock= "/tmp/ssh-xx3lkwhz/agent.4242"
Declare-x ssh_client= "10.3.37.152 2236 22"
Declare-x ssh_connection= "10.3.37.152 2236 10.3.37.186 22"
Declare-x ssh_tty= "/DEV/PTS/2"
Declare-x term= "Linux"
Declare-x user= "Root"
Declare-x username= "Root"
As you can see, the environment variable is already set, and the path of the compiler that I want to add is already in path.

2, modify the profile file:
#vi/etc/profile
Add in:
Export path= "$PATH:/Opt/au1200_rm/build_tools/bin"

3. Modify the. bashrc file:
# VI/ROOT/.BASHRC
Add in:
Export Path= "$PATH:/opt/au1200_rm/build_tools/bin"

The latter two methods generally require a re-logoff system to take effect, and finally can be tested by the echo command:
# echo $PATH
See if the output is already/my_new_path this path.

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

"/bin", "/sbin", "/usr/bin", "/usr/sbin", "/usr/local/bin" and other paths are already in the system environment variables, if the executable file in these standard locations, in the terminal command line enter the software executable file name and parameters ( If parameters are required), enter.

If not in a standard location, the file name needs to be preceded by a full path. But it's too much trouble to run like this every time, a "once and for all" approach is to add this path to the environment variable. The command "path= $PATH: Path" can add this path to an environment variable, but exiting the command line will fail. This line needs to be added to the environment variable file in order to be permanently active. There are two files to choose from: "/etc/profile" and ". Bash_profile" in the user's home directory, "/etc/profile" is valid for all users in the system, and ". Bash_profile" in the user's home directory is only valid for this user.

"Path= $PATH: Path 1: Path 2: ...: path n", which means that the path to the executable file includes the path originally set, and also includes all paths from "Path 1" to "Path N". When the user enters a string of characters and presses ENTER, the shell will find the corresponding executable file in these paths in turn and hand it over to the system core execution. The "$PATH" means that the path originally set is still valid, so be careful not to miss out. Some software may also have an environment variable of type "PATH" that needs to be added, but the method is the same, and you also need to be aware of "$".

Note that, unlike Dos/window, the path names in the UNIX class system environment variables are separated by colons, not semicolons. In addition, the more loaded the software, the more environment variables, in order to avoid confusion, it is recommended that all statements are added at the end of the file, in the software installation order.

The format is as follows ():

# Software Name-version number

Path= $PATH: Path 1: Path 2: ...: path n

Other environment variables =$ other environment variables: ...

In "Profile" and ". Bash_profile", "#" is a comment symbol that is written here without any effect except visual separation.

Setup is complete, log off and log back in, and the settings take effect. If you do not log off, executing these statements directly in the shell can also take effect, but the scope is limited to the shell that executes the statements.

Once the relevant environment variable is in effect, you don't have to run into the software's executable directory.

This article is from "Ah Kai" blog, please be sure to keep this source http://kaile.blog.51cto.com/12459560/1916397

The role of Linux export