在 ITPub 论坛上，最近有朋友发起了一个”请列出你在从事DBA生涯中,最难以忘怀的一次误操作“话题讨论，如果有足够的耐心看下去的话，会发现很多误操作都是类似的，最上镜的就是这个操作系统级别的 “rm -f” / “rm -rf” 了。
在那本著名的 Unix 痛恨者手册 上，rm 问题也作为一个罪状而提出。的确，Unix/Linux 的这个 rm 的 -f 参数是系统管理员（SA)乃至数据库管理员(DBA)最容易引发系统灾难的导火索。
如何避免这样的灾难发生呢?
如果一个人能不犯任何误操作就好了。但这是不可能的。我相信肯定有很多 DBA 或 SA 到现在也没烦过这样的错误，但不要忘了墨菲定律的诅咒。
1.有安全的 rm 命令麽?
一种比较理想的是如果编译源代码的时候把这个 -f 选项去掉，肯定能让不少人少犯错误。不过搜索了整个网络，好像还真没有具体如何操作的。Sun 的 Solaris 10 对 rm 作了一点改进处理，”rm -rf /” 是不允许的。可惜的是 “rm -rf *”类似的操作是没限制的。另外，对于其他系统也不可用。或许，将来 GNU/Linux 能有改进。
2.Alias 方式
第二个方式是在 Profile 层次上设置命令别名( alias ).
alias rm="rm -i"
这也是最常用的方式。如果脚本上直接调用了 rm 命令的全路径，还是不管用的。这其实也是如果功能上没办法完全禁止，那就提高用户的使用成本 :)
3.替代命令
第三个方法是使用替代命令。如用一个 del 命令来替代 rm. 这个就要挑战用户的使用习惯了。真的会始终用替代命令麽? 这个方式需要注意的是，无论如何不要真的把 rm 命令挪走(比如物理的 rename 名字)，如果这样，是很糟糕的策略。
4.修改权限
也有不少人直接把 rm 的权限修改，比如只允许 root 用户而不允许普通用户执行命令。这在调用一些脚本或者编译文件的时候，很容易引来很多麻烦。
任何一种策略，如果要扩大应用到一个团队的话，还需要考虑使用习惯对其他成员带来的影响。毕竟，”不爽”也会让很多人更容易犯错。
最后，友情提示，有的人经常通过层层跳板 Login 到主机上，可能会因为忘记了”身在何处” 而犯错误，最管用的方式是设置一下 PS1 环境变量。比如我在 Dreamhost 上用这样的：
PS1="\n\e[1;37m[\e[m\e[1;32m\u\e[m\e[1;33m@\e[m\e[1;35m\h\e[m \e[4m\`pwd\`\e[m\e[1;37m]\e[m\e[1;36m\n\e[m\\$ "
–EOF–
挺醒目，出了难看了点没啥其他问题
我的比较初级，纯粹出于好玩
PS1=’${debian_chroot:+($debian_chroot)}\[\033[01;36m\]C:\w \[\033[00m\]> ‘
我觉得挺可恶的一个命令就是 crontab -r。
他最可恶之处不在于没有提示就删除crontab，
而在于r和e两个键太近，有时候想“-e”却“-r”了
随着一个回车，all gone with Wind~.
所以大家要备份好crontab啊。
难看点没啥，关键是不能出错，
像我就干过想reboot自己电脑结果reboot了服务器的事，哈哈
嗯，学windows，加个回收站就可解决问题
防止rm 我用 touch — -i ，重要目录都可以这样。
alias 毕竟有时候不方便，不过对于不经常操作文件的情况下好用，毕竟删除文件恢复麻烦。
留言不好用所以发到这里
看你blog很久了，不过有件事情想麻烦你一下
我们在制作一个web2.0的网站，用mysql,目前碰到了一些数据库的性能问题，我们想请人来咨询一次，不知道你能否介绍一两个交友经验的mysql dba（当然你能出马更好）。
btw:我也喜欢the cure,虽然去年那张我不喜欢
加了回收站也不一定好用
因为我每次删除文件都习惯按住Shift
最好的办法是看好了在回车，加alias更容易出问题，比如你在一台机器上习惯了这个alias，到另一台机器上还会以为有确认提示，但是按完回车发现没有的时候就晚了。
windows好些，不过也存在问题，比如按CTRL C，结果按到CTRL X上，也会把生产数据搞掉。
熊猫烧香那位当DBA太曲才了，应当去当导演.
针对PS1的设置，有2个疑问：
1.后面的换行 [1;36m\n\e[m\ 这样设置的意义是什么呢？我这样设置以后使用ctrl+w后，或者set -o vi 切换一些命令时有时候出现异常，无法回到正确的行起始位置，不知道其他人是否也有这样的问题？
2.有些网站的资料显示：
还需要将全部非打印字符用专用的 bash 转义序列 “\[” 和 “\]” 括起来。
类似这种：\[ \e[1;32m \]
http://www.4ucode.com/Study/Topic/1611190
这个信息看起来有问题？实际是不需要的。