在 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–
google+
Linux系統中如何恢復使用rm f 刪除的檔案
第一步 使用 rm f 檔案刪除命令刪除某乙個檔案，比如我刪除目錄 home saas cloud finance 下的 cfpu saas finance provider 0.0.1.jar檔案，如下 rm rf home saas cloud finance cfpu saas finance...
如何避免程式設計中的BUG
這段時間的開發總是在自己給自己挖坑，進入了乙個創造bug登峰造極的階段，前兩天看了一篇類似雞湯的東西 為什麼你有10年經驗，但成不了專家 上面提到了刻意練習度的問題，很有道理，前提是你要進入 自動狀態 簡而言之就是下意識的去做出反應，但是就像有人說的，你的努力程度還到不了跟別人拼天賦的地步，還沒有到...
UNIX程序的環境
在學習程序之前，先來了解下程序的執行環境。main函式 程序總是從main函式開始執行的，我們程式設計時，程式執行也是從main函式執行的，它的原型如下 int main int argc,char argv argc是命令列引數的數目，argv是指鎮陣列，即指向指標的指標,可以寫 測試一下 inc...