我们的系统管理员在服务器上安装了一个软件应用程序（Maven），并告诉所有人将/usr/local/maven/bin/文件夹添加到其路径中。
我认为，从/bin文件夹（或每个人都在其路径中的其他文件夹）中链接该文件夹中的几个程序可能会更方便：
ln -s /usr/local/maven/bin/* /bin
它是否正确？我的建议有一些隐藏的副作用吗？
我们的系统管理员在服务器上安装了一个软件应用程序（Maven），并告诉所有人将/usr/local/maven/bin/文件夹添加到其路径中。
我认为，从/bin文件夹（或每个人都在其路径中的其他文件夹）中链接该文件夹中的几个程序可能会更方便：
ln -s /usr/local/maven/bin/* /bin
它是否正确？我的建议有一些隐藏的副作用吗？
Answers:
您通常不/usr/local/*与链接/bin，但这更多是历史做法。通常，有一些“技术性”原因导致您无法按照建议进行操作。
链接到可执行文件/bin可能会导致问题：
可能最大的警告是，如果您使用的系统是由某种软件包管理器（例如RPM，dpkg，APT，YUM，pacman，pkg_add等）管理的软件包，在这种情况下，通常需要让软件包经理做的工作和管理目录，例如/sbin，/bin，/lib，和/usr。一个例外是/usr/local，通常按照您认为适合的包装放置在一个安全的地方，而不必担心软件包管理器会干扰您的文件。
通常，为之构建的可执行文件/usr/local会将此PATH硬编码到其可执行文件中。/usr/local这些应用程序的安装过程中可能还包含一些配置文件。因此，仅链接到可执行文件可能会导致这些应用程序.cfg稍后找到文件时出现问题。这是这种情况的示例：
$ strings /usr/local/bin/wit | grep '/usr/local'
/usr/local/share/wit
/usr/local/share/wit/
.cfg主应用程序需要运行的“ helper”可执行文件也可能发生与查找文件相同的问题。这些也都需要链接到/usr/bin，知道这可能会出现问题，并且仅在您实际尝试执行链接的应用程序时才会显示。
注意：通常，最好避免诱惑链接到中的一个关闭的应用程序/usr/bin。
而是让所有用户提供此管理，管理员可以$PATH通过在/etc/profile.d目录中添加相应的文件来轻松地将其添加到每个人的盒子中。
像这样的文件/etc/profile.d/maven.sh：
PATH=$PATH:/usr/local/maven/bin
通常，您以管理员身份执行此操作，而不是以此污染所有用户的设置。
现在，大多数发行版都提供了另一个名为alternatives（Fedora / CentOS）或update-alternatives（Debian / Ubuntu）的$PATH工具，您也可以使用它们循环进入工具之外的工具/bin。最好使用这样的工具，因为这些工具更加符合大多数管理员认为的“标准做法”，因此使系统更容易从一位管理员移交给另一位管理员。
这个工具在建立链接方面做类似的事情/bin。但是它可以管理这些链接的创建和销毁，因此，通过工具进行的设置与直接按照您的建议进行的设置相比，更容易理解系统的预期设置。
在这里，我使用该系统在一个盒子上管理Oracle的Java：
$ ls -l /etc/alternatives/ | grep " java"
lrwxrwxrwx. 1 root root 73 Feb 5 13:15 java -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/jre/bin/java
lrwxrwxrwx. 1 root root 77 Feb 5 13:15 java.1.gz -> /usr/share/man/man1/java-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz
lrwxrwxrwx. 1 root root 70 Feb 5 13:19 javac -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/bin/javac
lrwxrwxrwx. 1 root root 78 Feb 5 13:19 javac.1.gz -> /usr/share/man/man1/javac-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz
lrwxrwxrwx. 1 root root 72 Feb 5 13:19 javadoc -> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/bin/javadoc
lrwxrwxrwx. 1 root root 80 Feb 5 13:19 javadoc.1.gz -> /usr/share/man/man1/javadoc-java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64.1.gz
您可以看到此效果：
$ type java
java is /usr/bin/java
$ readlink -f /usr/bin/java
/usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.1.fc19.x86_64/jre/bin/java
/bin大多数系统管理员强烈建议不要使用in进行链接，但是：
/bin目录。这是一个例子。在Red Hat发行版中，如果RPM中已经存在文件，则使用RPM的发行版/bin将不会像您描述的那样安装在发行版的顶部，除非使用--replacefiles开关进行切换。因此，这并不是真正的技术原因。与其他目录相同。我了解您对操作系统“拥有”的说法，/bin但并不像您所说的那样彻底。
回答以下问题：
它是否正确？
不，这是一个糟糕的做法。
我的建议有一些隐藏的副作用吗？
是的，有几种副作用。根据您的应用程序，您的建议可能行不通，并且从长远来看可能会倒退或破坏。
有合理的理由不创建这样的符号链接：
管理员不是“所有者” /bin（请参阅注释1），因为此目录属于操作系统/发行版开发人员。另一方面，/usr/local是本地管理员构建的软件的传统位置，是非/opt/<packagename>捆绑软件的位置。如果您在中创建文件或链接/bin，则可能会被软件包安装覆盖，在这种情况下maven，操作系统可能会提供一个假设的软件包，如果本地软件包是从较新的版本创建的，则可能会导致回归。操作系统版本的源代码。例如，SVR4 pkgadd，debian dpkg，rpmredhat和slackware tarball都会盲目地覆盖您的符号链接。
某些应用程序确实会在调用它们的地方进行查找以检索配置文件，插件和类似资源。如果您通过符号链接调用该应用程序，则其代码可能无法跟随它，然后在这些资源文件/usr/bin所在的位置以外的地方查找这些文件。
可能还有其他二进制文件，如果已删除，因为您已经通过链接所有潜在命令将其与命令一起考虑了。/usr/local/maven/bin不将该目录添加到您的PATH中，将使它们不可用。
该maven2的页面告诉这个目录添加到您的PATH（准确地说：添加M2环境变量设置为路径，例如出口PATH = $ M2：$ PATH），通过使用不同的方法，你都打破了步骤，会不支持道路。当然，如果系统的大多数用户是潜在maven用户，则设置PATH全局而不是每个上都更有意义.profile。
注1：
The /bin directory usually doesn't receive modification
after installation. If it does, it's usually in the form
of package upgrades that we provide.
/bin/
Essential command executable (binaries) for all users (e.g., cat, ls, cp)
(especially files required to boot or rescue the system)
...
/opt/
Add-on application software packages
Pre-compiled, non ".deb" binary distribution (tar'ed..) goes here.
/opt/bin/
Same as for top-level hierarchy
/usr/bin
Platform-dependent, user-invoked executables. These are
commands users expect to be run as part of their normal
$PATH. For executables that are different on a 64-bit
system than on a 32-bit system, a wrapper that selects
the appropriate executable is placed here. See
isaexec(3C). An approved installation location for bun-
dled Solaris software. The analogous location for add-on
system software or for applications is
/opt/packagename/bin.
dpkg即使--force-overwrite不使用该选项，显示Debian的简单测试也不会保留现有链接：
# ls -l /usr/bin/banner
lrwxrwxrwx 1 root root 11 Feb 25 21:37 /usr/bin/banner -> /tmp/banner
# dpkg -i sysvbanner_1.0.15_amd64.deb
Selecting previously unselected package sysvbanner.
(Reading database ... 236250 files and directories currently installed.)
Unpacking sysvbanner (from sysvbanner_1.0.15_amd64.deb) ...
Setting up sysvbanner (1.0.15) ...
Processing triggers for man-db ...
# ls -l /usr/bin/banner
-rwxr-xr-x 1 root root 11352 May 7 2009 /usr/bin/banner
/bin或中安装了自己的软件/usr/bin。在发现隐藏或被破坏的系统二进制文件（最著名的是test）的问题后，逐步采用了将非系统二进制文件安装在其他地方的最佳实践。
如果要进行符号链接，最好将其链接到/usr/local/bin。在服务器上，我曾经将本地软件安装到/opt/NAME并将二进制文件符号链接到/usr/local/bin。
/opt。