公司的自动驾驶平台有一个组件叫做proxy，用来转换专用格式的topic到rostopic，这样就可以用ROS下的各种功能了。但是今天使用proxy无论如何都没法正常运行，始终反馈“direct://”，后面一个参数就反馈一行，两个参数就反馈两行，本来以为是平台的第三方库被我升级后不兼容老版本平台了，升级软件平台后问题依旧。

那么问题出在哪里了呢？越想越烦躁，开了很多终端在排查问题，情急之下在其中一个终端里忘记加载平台的环境变量就输入proxy了，竟然也出现了同样的反馈，按理来说加载环境变量前是无法使用proxy命令的，难道是操作系统里直接安装了一个proxy命令？茅塞顿开，使用which proxy，发现这个proxy的路径在/usr/bin/proxy，果然是系统里有一个同名的proxy命令，和平台里的proxy命令冲突了，由于终端打开后是自动执行~/.bashrc加载系统环境变量后再手动加载的自动驾驶平台的环境变量，所以输入proxy命令会优先调用操作系统里安装的proxy程序。

找到原因了就好办，百度了一下这个路径没有搜到什么有用的结果，google查了一下，查到了libproxy的wiki页面，libproxy的可执行文件就是/usr/bin/proxy，于是尝试sudo apt remove libproxy再按tab，调出来了libproxy-tools，回车确认remove后，提示卸载VLC的一系列组件，到此罪魁祸首浮出水面，原来是因为我前阵子安装VLC的时候自动安装了依赖项libproxy-tools，在/usr/bin/下生成了proxy可执行文件，造成了和自动驾驶平台内部的proxy命令冲突。

所以说，用在全局环境变量里的程序名还是要特殊一些，如果用了“proxy”、“debug”、“start”这种过于常见的名称，很容易出现类似的命令冲突问题。