Linux export指令用于設定或顯示環境變量。
在shell中執行程式時，shell會提供一組環境變量。export可新增，修改或删除環境變量，供後續執行的程式使用。export的效力僅及于該次登陸操作。
參數說明：
-f 代表[變量名稱]中為函數名稱。
-n 删除指定的變量。變量實際上并未删除，隻是不會輸出到後續指令的執行環境中。
-p 列出所有的shell賦予程式的環境變量。
shell與export指令
使用者登入到Linux系統後，系統将啟動一個使用者shell。在這個shell中，可以使用shell指令或聲明變量，也可以建立并運作shell腳本程式。運作shell腳本程式時，系統将建立一個子shell。此時，系統中将有兩個shell，一個是登入時系統啟動的shell，另一個是系統為運作腳本程式建立的shell。當一個腳本程式運作完畢，它的腳本shell将終止，可以傳回到執行該腳本之前的shell。從這種意義上來說，使用者可以有許多 shell，每個shell都是由某個shell（稱為父shell）派生的。
在子 shell中定義的變量隻在該子shell内有效。如果在一個shell腳本程式中定義了一個變量，當該腳本程式運作時，這個定義的變量隻是該腳本程式内的一個局部變量，其他的shell不能引用它，要使某個變量的值可以在其他shell中被改變，可以使用export指令對已定義的變量進行輸出。 export指令将使系統在建立每一個新的shell時定義這個變量的一個拷貝。這個過程稱之為變量輸出。
【轉載】Linux Source指令及腳本的執行方式解析
當我修改了/etc/profile檔案，我想讓它立刻生效，而不用重新登入；這時就想到用source指令，如:source /etc/profile
對source進行了學習，并且用它與sh 執行腳本進行了對比，現在總結一下。
source指令：
source指令也稱為“點指令”，也就是一個點符号（.）,是bash的内部指令。
功能：使Shell讀入指定的Shell程式檔案并依次執行檔案中的所有語句
source指令通常用于重新執行剛修改的初始化檔案，使之立即生效，而不必登出并重新登入。
用法：
source filename 或 . filename
source指令(從 C Shell 而來)是bash shell的内置指令;點指令(.)，就是個點符号(從Bourne Shell而來)是source的另一名稱。
source filename 與 sh filename 及./filename執行腳本的差別在那裡呢？
1.當shell腳本具有可執行權限時，用sh filename與./filename執行腳本是沒有差別得。./filename是因為目前目錄沒有在PATH中，所有"."是用來表示目前目錄的。
2.sh filename 重建立立一個子shell，在子shell中執行腳本裡面的語句，該子shell繼承父shell的環境變量，但子shell建立的、改變的變量不會被帶回父shell，除非使用export。
3.source filename：這個指令其實隻是簡單地讀取腳本裡面的語句依次在目前shell裡面執行，沒有建立新的子shell。那麼腳本裡面所有建立、改變變量的語句都會儲存在目前shell裡面。
舉例說明：
1.建立一個test.sh腳本，内容為:A=1
2.然後使其可執行chmod +x test.sh
3.運作sh test.sh後，echo $A，顯示為空，因為A=1并未傳回給目前shell運作./test.sh後，也是一樣的效果、
export指令_Linux export 指令用法詳解：設定或顯示系統環境變量 http://man.linuxde.net/export
export指令用于将shell變量輸出為環境變量，或者将shell函數輸出為環境變量。
一個變量建立時，它不會自動地為在它之後建立的shell程序所知。而指令export可以向後面的shell傳遞變量的值。當一個shell腳本調用并執 行時，它不會自動得到原為腳本（調用者）裡定義的變量的通路權，除非這些變量已經被顯式地設定為可用。export指令可以用于傳遞一個或多個變量的值到任何後繼腳本。
變量：指定要輸出或者删除的環境變量。
EnvironmentVariables - Community Help Wiki https://help.ubuntu.com/community/EnvironmentVariables
Environment variables provide a way to influence the behaviour of software on the system. For example, the "LANG" environment variable determines the language in which software programs communicate with the user.
Environment variables consist of names that have values assigned to them. For example, on a typical system in the US we would have the value "en_US.UTF-8" assigned to the "LANG" variable.
The meaning of an environment variable and the format of its value are determined by the application using it. There are quite a few well-known environment variables for which the meaning and the format have been agreed upon and they are used by many applications.
While simply setting an empty value to an environment variable, as shown in the example below, may nullify its effect in most cases, there are a few variables such as "POSIXLY_CORRECT" whose mere existence, even with an empty value, influences the behavior of programs.
The unset command can be used in order to completely erase the existence of an environment variable:
It is also possible to use the "-n" switch to the export command in order to un-export an environment variable and therefore demote it to become a shell variable while preserving its value.
Working principles of environment variables
A few simple principles govern how environment variables work and achieve their effect.
The values of environment variables are local, which means they are specific to the running process in or for which they were set. This means that if we open two terminal windows (which means we have two separate bash processes running), and change a value of an environment variable in one of the windows, that change will not be seen by the shell in the other window or any other program currently on the desktop.
When a parent process creates a child process, for example when we run the "gedit" command from the terminal and "bash" (the parent process) creates "gedit" (the child process), the child process inherits all the environment variables and values the parent process had.
This means that if we set a new value to the "LANG" environment variable in the terminal, and then run "gedit" from that same terminal, "gedit" will inherit the new value of "LANG", and therefore may display in a different language than the rest of the processes on the desktop. (See The LANGUAGE priority list, though.)
Note that because of the Process Locality principle explained above, once we run Gedit, changes to environment variables of the parent process will not be seen by the child process and vice-versa.
Note: in the Gnome graphical desktop environment, gnome-session is the parent process of all the processes running on the desktop. This fact (along with the Inheritance principle) is the key to our ability to powerfully influence the operation of our desktop with environment variables. The equivalent process in KDE is kde-session.
The names of environment variables are case sensitive. This means that lang is not the same variable as LANG, Lang, or laNg.
It is a common practice to name all environment variables with only English capital letters and underscore (_) signs.
Bash's quick assignment and inheritance trick
The bash shell has a trick to allow us to set one or more environment variables and run a child process with single command. For example, in order to set the "LANGUAGE" and "FOO" environment variables and then run "gedit", we would use the following command:
Note: When using this command, the new values are only assigned to the environment variables of the child process (in this case gedit). The variables of the shell retain their original values. For instance, in the example above, the value of "LANGUAGE" will not change from its original value, as far as subsequent commands to the shell are concerned.
A similar behaviour can be achieved with other shells by using the env command.
Persistent environment variables
So far we've only discussed ways set an environment variable value temporarily until the shell session in which it was set is closed. One may wonder if there is a way to somehow permanently set an environment variable to a certain value.
Suitable files for environment variable settings that should affect just a particular user (rather than the system as a whole) are~/.pam_environment and ~/.profile. After having edited one of those files, you should re-login in order to initialize the variables.
This file is specifically meant for setting a user's environment. It is not a script file, but rather consists of assignment expressions, one per line. This example sets the variable FOO to a literal string and modifies the PATH variable:
Note:
When doing a simple variable assignment like the FOO=bar example, quotes have not special meaning. This means that values cannot contain spaces.
The syntax used for modifying PATH, which differs from the syntax of shell script files, is required for variable expansion to work. Some variables, like HOME, might not be set at the time ~/.pam_environment is parsed. See /etc/security/pam_env.conf for more details.
~/.pam_environment is written to when you use various GUIs to set the language or regional formats. Consequently, if you for instance set LC_TIME by editing ~/.pam_environment manually, your entry will be overwritten if you afterwards use the Language Support GUI to change the regional formats setting.
In this file you can also place environment variable assignments, since it gets executed automatically by the DisplayManager during the start-up process desktop session as well as by the login shell when one logs in from the textual console. This is a ~/.profile equivalent of the above example:
Note: The code in ~/.profile is run after ~/.pam_environment has been read. That makes ~/.profile suitable to use if you want to override a locale related variable that was set in ~/.pam_environment via e.g. Language Support.
If you are using KDE, see also the KDE User-base page on this topic.
Shell config files such as ~/.bashrc, ~/.bash_profile, and ~/.bash_login are often suggested for setting environment variables. While this may work on Bash shells for programs started from the shell, variables set in those files are not available by default to programs started from the graphical environment in a desktop session.
A suitable file for environment variable settings that affect the system as a whole (rather than just a particular user) is /etc/environment. An alternative is to create a file for the purpose in the /etc/profile.d directory.
This file is specifically meant for system-wide environment variable settings. It is not a script file, but rather consists of assignment expressions, one per line.
Note: Variable expansion does not work in /etc/environment.
Files with the .sh extension in the /etc/profile.d directory get executed whenever a bash login shell is entered (e.g. when logging in from the console or over ssh), as well as by the DisplayManager when the desktop session loads.
You can for instance create the file /etc/profile.d/myenvvars.sh and set variables like this:
While /etc/profile is often suggested for setting environment variables system-wide, it is a configuration file of the base-files package, so it's not appropriate to edit that file directly. Use a file in /etc/profile.d instead as shown above. (Files in /etc/profile.d are sourced by /etc/profile.)
/etc/default/locale is specifically meant for system-wide locale environment variable settings. It's written to by the installer and when you use Language Support to set the language or regional formats system-wide. On a desktop system there is normally no reason to edit this file manually.
The shell config file /etc/bash.bashrc is sometimes suggested for setting environment variables system-wide. While this may work on Bash shells for programs started from the shell, variables set in that file are not available by default to programs started from the graphical environment in a desktop session.
Environment variables - ArchWiki https://wiki.archlinux.org/index.php/Environment_variables
In principle, any shell script can be used for initializing environmental variables, but following traditional UNIX conventions, these statements should be only be present in some particular files.
An environment variable is a named object that contains data used by one or more applications. In simple terms, it is a variable with a name and a value. The value of an environmental variable can for example be the location of all executable files in the file system, the default editor that should be used, or the system locale settings. Users new to Linux may often find this way of managing settings a bit unmanageable. However, environment variables provide a simple way to share configuration settings between multiple applications and processes in Linux.
單使用者變量和全使用者變量
Most Linux distributions tell you to change or add environment variable definitions in <code>/etc/profile</code> or other locations. Keep in mind that there are also package-specific configuration files containing variable settings such as <code>/etc/locale.conf</code>. Be sure to maintain and manage the environment variables and pay attention to the numerous files that can contain environment variables. In principle, any shell script can be used for initializing environmental variables, but following traditional UNIX conventions, these statements should be only be present in some particular files.
The following files should be used for defining global environment variables on your system: <code>/etc/environment</code>, <code>/etc/profile</code> and shell specific configuration files. Each of these files has different limitations, so you should carefully select the appropriate one for your purposes.
<code>/etc/environment</code> is used by the pam_env module and is shell agnostic so scripting or glob expansion cannot be used. The file only accepts <code>variable=value</code> pairs. See pam_env(8) and pam_env.conf(5) for details.
Global configuration files of your shell, initializes variables and runs scripts. For example Bash#Configuration files or Zsh#Startup/Shutdown files.
<code>/etc/profile</code> initializes variables for login shells only. It does, however, run scripts and can be used by all Bourne shell compatible shells.
In this example, we add <code>~/bin</code> directory to the <code>PATH</code> for respective user. To do this, just put this in your preferred global environment variable config file (<code>/etc/profile</code> or <code>/etc/bash.bashrc</code>):
Note: The dbus daemon and the user instance of systemd do not inherit any of the environment variables set in places like <code>~/.bashrc</code> etc. This means that, for example, dbus activated programs like Gnome Files will not use them by default. See Systemd/User#Environment variables.
You do not always want to define an environment variable globally. For instance, you might want to add <code>/home/my_user/bin</code> to the <code>PATH</code> variable but do not want all other users on your system to have that in their <code>PATH</code> too. Local environment variables can be defined in many different files:
<code>~/.pam_environment</code> is the user specific equivalent of <code>/etc/security/pam_env.conf</code> [1], used by pam_env module. See pam_env(8) and pam_env.conf(5) for details.
User configuration files of your shell, for example Bash#Configuration files or Zsh#Startup/Shutdown files.
<code>~/.profile</code> is used by many shells as fallback, see wikipedia:Unix shell#Configuration files.
To add a directory to the <code>PATH</code> for local usage, put following in <code>~/.bash_profile</code>:
To update the variable, re-login or source the file: <code>$ source ~/.bash_profile</code>.
單會話的變量
Sometimes even stricter definitions are required. One might want to temporarily run executables from a specific directory created without having to type the absolute path to each one, or editing shell configuration files for the short time needed to run them.
In this case, you can define the <code>PATH</code> variable in your current session, combined with the export command. As long as you do not log out, the <code>PATH</code> variable will be using the temporary settings. To add a session-specific directory to <code>PATH</code>, issue:
![linux-svn解除安裝與安裝[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)