GitLab 的惨剧让我造了个防 rm 的轮子： rm-protection

[discrete]

rm-protection

GitLab 的惨剧想必大家都知道了：rm -rf了生产服务器上的数据库。常在河边走，哪能不湿鞋。即便是再认真，总是有失误的风险。

现在网上已经流行了数种方法： rm -i , trash-cli 等等。rm -i 显然并不实用：想必没人能忍受每个文件都被问一次？况且就 GitLab 的情况，rm -i并不能起保护作用。trash-cli相当于启用了回收站，但是这又会带来一些小麻烦（比如在磁盘被 log 挤爆的情况下）。

rm-protection 则采取了一种全新的思路：由用户自行设置一个安全问题来保护文件，在删除时询问相应的问题。想象一下，若 YP 在执行删除时突然被问一句：「 Which server are you on? 」，还会出现这样的惨剧吗？

快速开始

rm-protection 几乎完全兼容rm，因此可以作为 alias 使用。

1. 从 PyPi 中安装并为 rm-p 创建 alias 。

   pip install rm-protection & alias rm="rm-p"

2. 使用 protect 命令保护你想要保护的文件或者文件夹。

3. Happy rm-ing!

原理

rm-protection 获取 arguments 后，会逐一检测是否存在 .<filename>.rm-protection 文件。若存在，则询问用户，否则将不再传递这个 argument 。安全的 argument 将被传递给 rm 进行删除。

栗子：

它也能保护批量的递归删除：

与其他工具的对比

参见 GitHub 中的表格。

未来？

若是这个工具能被推广使用，团队协作之间可以大有功用。在软件、文件分发时，分发者可以提前保护文件防止误删。在开发和部署时也可提前保护文件，防止在生产环境中的误删。

贡献

Github 欢迎 PR, 提 Issue 或者 Star ：）

[loading]

简单问题复杂化，大师级！

[discrete]

@SharkIng 当你必须输入 I'm going to delete production database 的时候难道还不会心里一惊 2333

当然了不可能所谓完全解决问题，只是试图以最小的日常影响（比如与 rm -i 相比）做到最大的保护。

[ayayui]

rm 列出要删除的文件，确认后才删除。

[phrack]

也许允许人犯一些错误更好，不然世界就少了乐趣和故事了。

[discrete]

@loading 在特定的场合复杂化我觉得是有益的，比如 GitHub 会在你删除 repo 的时候让你确认 repo 的名字。

这个工具同理，不会影响你 rm 的日常操作，但是在删除极其重要的文件时提供尽可能的保护。

[discrete]

@cuebyte 嘛确实……（捂脸逃（其实当时不用 python2 只是因为 raw_input() 的问题，加个判断就兼容了。

[discrete]

@yangqi 所以最终还是要问对的问题，比如：
「你删的是啥数据库」
「测试」
「滚！」

[lanxyou]

批量删除的时候会不会把保护文件先删除了？

[discrete]

@lanxyou 不会，会提前检索保护文件。

[gfexfizv]

可以 alias rm 为 move ，移动到一个垃圾文件夹里面

[harry890829]

用 alias 重定义 rm 啊，改为 move ，然后丢到垃圾文件夹，定期清理垃圾文件夹就好了

[finian]

稍微有点复杂了，不如 trash 的方案来得简单。不过这些方案都无法彻底避免杯具，人和流程都是不可靠的，唯有使用自动化工具才能最大程度地避免失误

[sox]

npm i -g trash-cli
alias rm=“ trash ”

[discrete]

@finian
@sox
@gfexfizv

trash 类方案确实是我之前见过最好的。
但是 GitLab 让我想起了另外的情况：想象一下空间被 spam 挤爆（类似 GitLab ），大概是清空垃圾箱之后才 Oh shit 吧。在图形界面里，还不是有误删垃圾桶的情况发生？

[qianguozheng]

例子中的 gif 图片用什么工具获得的？

[discrete]

@qianguozheng macOS 自带 QuickTime 录屏，然后 Google 里随便找了一个在线的视频转 gif 工具。