今天我第一次看到了部分意外删除同事主目录的可能性（在项目的关键阶段丢失了2个小时）。 我非常担心它会开始考虑问题并提供可能的解决方案。
在他的情况下，一个名为'〜'的文件以某种方式进入了一个测试文件夹，在用rm -rf删除后...当rm到达文件时bash将其扩展到他的主文件夹（他设法使用CTRL-C几乎及时）。 如果有一个名为'*'的文件，可能会发生类似的问题。
我的第一个想法是阻止创建具有“危险名称”的文件，但这仍然无法解决问题，因为mv或其他角落情况也可能导致风险情况。
第二个想法是创建一个监听器（不知道这是否可能）或rm的别名，它检查它处理的文件，如果发现危险，则跳过发送消息。 类似的东西：
第三个想法：有没有人已经完成或处理过这个问题？ ：
答案 0 :(得分：7)
将主目录中的关键文件检入源代码控制实际上是非常合理的。除了防止您刚刚遇到的情况，它还能很好地控制.bashrc等版本。
答案 1 :(得分：2)
由于shell可能会扩展参数，因此您无法真正捕捉到这样的“危险”名称。
你可以将'rm -rf'别名为'rm -rfi'（交互式），但如果你的意思是'rm -rf *'，这可能会非常繁琐。
你可以将'rm'别名为'mv $ @ $ HOME / .thrash'，并且有一个单独的命令来清空thrash，但是如果你真的想要删除文件因为磁盘配额或类似的话可能会导致问题。
或者，您可以保留适当的备份或使用允许“取消删除”的文件系统。
答案 2 :(得分：2)
事故确实发生了。你只能减少它们的影响。
版本控制（常规签到）和备份在这里都至关重要。
如果我无法登记（因为它还没有办法），我会备份到USB记忆棒。
如果截止日期临近，那么备用频率就会增加，因为墨菲会在最不适当的时刻出现。
答案 3 :(得分：1)
我做的一件事总是在我的$ HOME中有一个名为“-i”的文件。
我的另一个提示是始终使用“./*”或find而不是普通的“*”。
答案 4 :(得分：0)
版本控制建议得到了我的支持。我建议所有事情，而不仅仅是来源。
另一个想法是备份和存档的服务器上的共享驱动器。
第三个想法是为每个人购买一个独立的外置硬盘，让他们备份本地硬盘。这是一件好事，因为有两种硬盘驱动器：那些已经发生故障的硬盘驱动器和未来的硬盘驱动器。
答案 5 :(得分：0)
您还可以从rm创建一个别名，该别名通过一个简单的脚本运行，该脚本可以转义所有字符，从而有效地阻止您使用通配符。然后创建另一个运行通过实际rm而不转义的别名。如果你确定，你只会使用第二个。那么再说一遍，这有点像rm -rf。
我个人喜欢的另一个选项是创建一个别名，通过脚本重定向，然后将所有内容传递给rm。如果脚本发现任何危险字符，如果你想继续，它会提示你Y / N，N取消操作，Y继续正常。
答案 6 :(得分：0)
我工作的一家公司我们有一个cron工作，每半小时运行一次，将所有源代码文件从每个人的主目录复制到系统其他位置的备份目录结构，只使用find。
这不会阻止实际删除，但它确实最大限度地减少了多次丢失的工作。
答案 7 :(得分：0)
这真的很奇怪 - 为什么bash会扩展两次？
一旦*扩展到
old~
this~
~
然后不应该进行进一步的替换！
我在我的mac上勇敢地测试了它，它只是删除了〜，而不是我的主目录。
你的同事有可能以某种方式编写了扩展它的代码吗？
e.g。
ls | xargs | rm -rf
答案 8 :(得分：0)
您可以禁用文件名生成（通配）：
set -f
使用Bash内置函数可以在文件路径中转义特殊字符：
filepath='/abc*?~def'
filepath="$(printf "%q" "${filepath}")"
filepath="${filepath//\~/\\~}"
printf "%s\n" "${filepath}"
答案 9 :(得分：0)
我在〜/ .basrc
中使用它别名rm =“rm -i”
rm在删除任何内容之前提示，并且可以使用-f标志或escabing来绕过别名，例如， \ rm文件
贬低问题是的;解决不了。