在shell脚本设置了环境变量，如export LIBRARY_PATH=./lib/，执行了此脚本后, 在执行生成的可执行文件，提示错误
error while loading shared libraries: libww.so: cannot open shared object file: No such file or directory
但是如果把export那句话单独在命令行运行，在gcc编译代码后不会出现问题
怎么也想不通，为什么脚本执行了，设置了环境变量，但是运行可执行文件总是失败。
查看大牛博客，终于发现
原因是执行脚本用./test.sh的方式，如果采用source test.sh，则环境变量会生效。
./XXX.sh的时候，脚本里面打印PATH是改了，但是在终端echo $PATH却没有看到变化，因为这样执行等于说不在当前进程
那么。这是为什么呢？
关键：直接执行一个脚本文件是在一个子shell中运行的，而source则是在当前shell环境中运行的。
1、执行脚本时是在一个子shell环境运行的，脚本执行完后该子shell自动退出；
2、一个shell中的系统环境变量才会被复制到子shell中（用export定义的变量）
3、一个shell中的系统环境变量只对该shell或者它的子shell有效，该shell结束时变量消失（并不能返回到父shell中）。
4、不用export定义的变量只对该shell有效，对子shell也是无效的。
另：
---- 在UNIX系统中,我们在运行shell程序或系统命令的过程如下:
---- 假设在当前的shell环境下,我们运行ps -f命令.
---- 首先,当前的shell会调用:fork()命令,产生一个subprocess,该子进程完全复制了父进程的所有环境;
---- 之后,当前的shell会调用:exec ps -f命令,在新的子进程的环境中,运行ps -f 命令.子进程的环境变量会根据新的应用进行调整,并使之运行,当应用完成之后,子进程结束,返回到父进程.
---- 因此,通过上述过程分析,$cbpsprofile的运行的结果就可以预见,该shell程序的运行,环境变量重新赋值仅仅在子进程中,程序运行完后,返回到父进程,父进程的环境变量是不会受到影响的
