☰

为什么源代码卸载脚本在删除文件之前会“cd”进入目录？

tag-icon • tag-icon linux command-line uninstall
为什么源代码卸载脚本在删除文件之前会“cd”进入目录？

因此，我不得不卸载一些我在 macOS Sierra（10.12.2）上从源代码编译的命令行工具，并注意到当我运行时在终端中返回了这些类似结构的命令sudo make uninstall：

sudo make uninstallHTop的输出：

( cd '/usr/local/share/applications' && rm -f htop.desktop )
( cd '/usr/local/bin' && rm -f htop )
( cd '/usr/local/share/man/man1' && rm -f htop.1 )
( cd '/usr/local/share/pixmaps' && rm -f htop.png )

sudo make uninstallMTR的输出：

( cd '/usr/local/share/man/man8' && rm -f mtr.8 )
( cd '/usr/local/sbin' && rm -f mtr )

sudo make uninstallSSHPASS的输出：

( cd '/usr/local/bin' && rm -f sshpass )
( cd '/usr/local/share/man/man1' && rm -f sshpass.1 )

我觉得很奇怪，每个命令本质上都是cd进入一个目录，然后rm -f与该命令一起运行cd。为什么不直接rm -f使用完整路径的文件，就像这样；例如使用这里的 SSHPASS 输出：

rm -f '/usr/local/bin/sshpass'
rm -f '/usr/local/share/man/man1/sshpass.1'

我理解手动输入此类命令时需要保证安全，但在预设脚本的情况下（其过程本身应该干净且无风险），将 make 脚本删除项目作为复合命令有什么好处？

答案1

我只能认为这是由于过去曾经犯过的一个错误造成的。

基本上有人不小心在文件路径中插入了一个额外的空格，然后将其删除；参见例如 GitHub 上的这个提交。

通过这样做cd '/usr/local/share/man/man8' && rm -f mtr.8- 如果命令的第一部分，即cd失败，它将根本不会运行rm -f。这是一种故障保护。

相关内容