将来更改时，如何加固bash脚本以免造成损害？

因此，我删除了我的主文件夹（或更确切地说，是我拥有写权限的所有文件）。发生的是我有

build="build"
...
rm -rf "${build}/"*
...
<do other things with $build>

在bash脚本中，并在不再需要$build时删除了声明及其所有用法-而是rm。Bash高兴地扩展到rm -rf /*。是的

我感到很愚蠢，安装了备份，重新进行了丢失的工作。试图摆脱耻辱。

现在，我想知道：什么是编写bash脚本以使此类错误不会发生或者至少不太可能发生的技术？例如，我写过吗

FileUtils.rm_rf("#{build}/*")

在Ruby脚本中，解释器会抱怨build没有声明，因此该语言可以保护我。

我在bash中考虑过的内容，除了合计rm（相关问题中的许多答案都提到了，这并非没有问题）：

1. rm -rf "./${build}/"*
   那会杀死我目前的工作（一个Git回购），但没有别的。
2. rm在当前目录之外执行操作时，需要进行交互的变体/参数化。（找不到任何内容。）类似的效果。

是这样吗，或者还有其他方法可以编写这种意义上的“健壮” bash脚本吗？

set -u

要么

set -o nounset

这会使当前的shell将未设置的变量的扩展视为错误：

$ unset build
$ set -u
$ rm -rf "$build"/*
bash: build: unbound variable

set -u和set -o nounset是POSIX shell选项。

但是，空值不会触发错误。

为此，使用

$ rm -rf "${build:?Error, variable is empty or unset}"/*
bash: build: Error, variable is empty or unset

的扩展${variable:?word}将扩展为的值，variable除非它为空或未设置。如果为空或未设置，word则将在标准错误上显示，并且外壳程序会将扩展视为错误（该命令将不会执行，并且如果在非交互式外壳程序中运行，则会终止）。遗漏:只会针对未设置的值触发错误，就像under一样set -u。

${variable:?word}是POSIX参数扩展。

除非set -e（或set -o errexit）也同样有效，否则这些都不会导致交互式外壳终止。${variable:?word}如果变量为空或未设置，则导致脚本退出。set -u如果与一起使用，将导致脚本退出set -e。

至于第二个问题。没有方法限制rm不能在当前目录之外工作。

GNU的实现rm有一个--one-file-system选项，可以阻止它递归地删除已挂载的文件系统，但这与我所相信的非常接近，而无需将rm调用包装在实际检查参数的函数中。

附带说明： ${build}完全等同于，$build除非扩展是作为字符串的一部分发生的，其中紧随其后的字符是变量名中的有效字符，例如in "${build}x"。

我将建议使用test/进行常规验证[ ]

如果您这样编写脚本，那将是安全的：

build="build"
...
[ -n "${build}" ] || exit 1
rm -rf "${build}/"*
...

在[ -n "${build}" ]检查到"${build}"是一个非零的长度的字符串。

该||是在bash逻辑OR运算符。如果第一个命令失败，它将导致另一个命令运行。

这样，本来${build}就为空/未定义/等。该脚本将退出（返回码为1，这是一个通用错误）。

万一您删除了所有用途，这也将为您提供保护，${build}因为它[ -n "" ]始终是错误的。

使用test/ 的优点[ ]是还可以使用许多其他更有意义的检查。

例如：

[ -f FILE ] True if FILE exists and is a regular file.
[ -d FILE ] True if FILE exists and is a directory.
[ -O FILE ] True if FILE exists and is owned by the effective user ID.

在您的特定情况下，我过去对“删除”进行了重新处理以改为移动文件/目录（假设/ tmp与目录位于同一分区）：

# mktemp -d is also a good, reliable choice
trashdir=/tmp/.trash-$USER/trash-`date`
mkdir -p "$trashdir"
...
mv "${build}"/* "$trashdir"
...

在幕后，这会将顶级文件/目录引用从源移动到$trashdir同一分区上的目标目录结构，而无需花费时间遍历目录结构并立即释放每个文件的磁盘块。在系统处于活动状态时，这会产生更快的清除速度，以换取稍慢的重新引导（/ tmp在重新引导时被清除）。

另外，对于要消耗大量磁盘空间的进程（例如，构建），要定期清理/tmp/.trash-$USER的cron条目将使/ tmp不再填满。如果您的目录与/ tmp在不同的分区上，则可以在该分区上创建类似/ tmp的目录，然后使用cron清除该目录。

但是，最重要的是，如果您以任何方式修改变量，则可以在清理发生之前恢复内容。

当变量未初始化时，使用bash参数替换指定默认值，例如：

rm -rf $ {变量：-“ /不存在”}

我总是尝试以一行开始我的Bash脚本#!/bin/bash -ue。

-e的意思是“失败上第一uncathed é RROR”;

-u意思是“第一次使用失败的ü ndeclared变量”。

在出色的文章中找到更多详细信息使用非官方Bash严格模式（除非您放心调试）。作者也建议使用，set -o pipefail; IFS=$'\n\t'但出于我的目的，这太过分了。

检查变量是否已设置的一般建议是防止此类问题的有用工具。但是在这种情况下，有一个更简单的解决方案。

最有可能不需要$build为了删除它们而删除目录的内容，而不是实际$build目录本身。因此，如果您跳过无关的内容，*那么rm -rf /默认情况下，过去十年中大多数rm实现将拒绝执行一个未设置的值（除非使用GNU rm的--no-preserve-root选项禁用此保护）。

跳过拖尾/以及将导致rm ''，这将导致错误消息：

rm: can't remove '': No such file or directory

即使您的rm命令未实现对的保护，此方法也有效/。

您正在用编程语言术语进行思考，但是bash是一种脚本语言：-)因此，对于完全不同的语言范例，请使用完全不同的指令范例。

在这种情况下：

rmdir ${build}

由于rmdir将拒绝删除非空目录，因此您需要先删除成员。你知道那些成员是什么吗？它们可能是脚本的参数，或者是从参数派生的，因此：

rm -rf ${build}/${parameter}
rmdir ${build}

现在，如果您在其中放置一些其他文件或目录（例如临时文件或您不应该使用的文件），rmdir则会引发错误。正确处理，然后：

rmdir ${build} || build_dir_not_empty "${build}"

这种思维方式对我很有帮助，因为……是的，去过那儿。