☰

添加 ./bin 是一个坏主意

tag-icon • tag-icon bash binary
添加 ./bin 是一个坏主意

我想不出为什么添加./bin到我的PATH环境中是一个非常糟糕的主意。

我通常bin在我正在处理的项目中创建文件夹，但我讨厌这样做，只要我位于带有文件夹的目录中并且该文件夹包含可执行文件，那么 bash 就会拾取文件夹bin/command，这会很好。commandbinbincommand

我需要令人信服的:D

答案1

、$HOME/bin和.通常./bin被视为安全风险。

对于这个$HOME/bin问题，一些“破解者”将一些脚本（例如名为 nano 的脚本）推送到该目录，然后它会等待，直到您运行类似的命令sudo nano /etc/hosts以获得即时 root 访问权限（将 nano 更改为 vi、emacs 等；命令并不重要，重要的是它可以执行的有效负载）。

对于.和./bin，仍然是同样的问题：添加一个在错误目录中运行的额外程序。

如果这些 ./bin/command 位于不同的目录而不是 /usr/local/bin （新的本地脚本的首选解决方案）中，这是因为它们执行不同的操作；如果运行错误怎么办？

如果您以相同的方式命名命令（让我们先调用，然后更新、提交、清理等），您可能正在处理目录，然后您会接到一个电话，然后换到另一个电话进行快速检查。挂断后，你的大脑会尝试恢复你正在做的事情，大多数时候会忘记你所做的快速“cd”（特别是如果屏幕上的所有内容似乎都指向正确的目录）并完成在错误的命令上运行目录（比如说清除你一个月所有工作的清理脚本）。

这可能看起来是一个无辜的错误，但很多人每天都会遇到这种情况！ :)

一个好的解决方法（或更好的解决方案）是使用别名：

alias proj1-cleanup=/srv/proj1/bin/cleanup

并添加正确的脚本cd以确保它在正确的目录上运行。

这样，通过$HOME/.alias添加您需要的各种脚本，您可以使用不同的命令来执行不同的操作，即使有人破解您的浏览器以创建文件$HOME/bin/ls或某些本地用户在任何目录上创建 bin/ls 文件，这些文件永远不会被执行，因为您的路径仍然指向正确的命令。

但是，嘿，这是个人选择；您知道当地的风险是什么以及命令的作用。

答案2

至少在 Ubuntu 上，这是默认用户配置文件的一部分：

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

我不认为这是一个问题，但由于它是用户可写的并且可以透明地拦截命令，所以人们可能会对此感到紧张。然而，显然这比 更安全./bin。

相关内容