2008/08/04

何時不要用 bash scripting?

怪了,最近怎麼常寫 bash scripting? 在問何時用 shell script 才是比較好的問題時,我覺得應該先了解一下,什麼時候最好不要用 shell script?

為何要用 shell script這篇有提到,我就翻譯成中文與大家分享。


  • 特別需要考量資源時,例如執行速度,shell script 在處理大量排序、hashing 或 recursion 等演算法上,相對會比較浪費時間。
  • 包含大量數學運算時,尤其 shell script 可以說無法處理浮點運算,雖然如同 sort 或 filtering 等可以借助其他常用的命令來解決,但是會讓運算效能打折扣。
  • 基於考量可攜性,shell script 雖然在 unix 系列移植性很大,但是光不同的 shell 本身就很難共用相同的 script, 要對硬體產生高移植性也是奢求。
  • 複雜的應用程式,我想這一點沒人會否定,畢竟 shell script 相對上比較沒有像結構化的演算法特性,例如資料結構的局限性,或是遞迴,或是變數本身在在都限制住往大的應用程式開發之路。
  • 對組織或公司影響深遠的關鍵應用程式最好別選擇用純 Shell scripting, 原因當然在前面有寫,最重要的是 shell script 也沒有很好的擴承特性,例如 OOP
  • 高安全性要求的情況下,包括整個系統的高度整合,系統的保護、系統的穩定、系統的堅固性上,shell script 都具高度爭議性。這裡面也包括 scripting 的先天特性,應用程式無法封裝起來,任何人都可以看到你的程式碼。
  • 包含聯鎖相依性的組成元素的專案也不適合,核心原因也跟前一議題一樣,尤其 shell script 的 lock 機制並不完善,因此在這議題的處理上容易出錯。
  • shell scripting 對大量檔案的處理只能一次處理一個檔案的逐次處理,很難有最佳化表現,若再考量 cache 或 index 等等因素的話,對檔案處理上毫無競爭力。
  • 具直覺性的多維陣列處理上,也非 shell script 擅長的,雖然 bash 具備陣列表示,總是不那麼自然。
  • 需要像 linkly-list 這類的稍微複雜點的資料處理上,shell script 就是無法勝任,更不用講什麼 Tree 或 graphics
  • 需要產生或處理圖形或圖形的介面時,雖然可以借助其他軟體套件像 tcl/tk, dialog 等等讓你在 shell scripting 下也能有 GUI, 畢竟,效率會比較差,彈性、擴充性也都是值得考量的。
  • 需要直接存取系統硬體時,shell script 也比較少彈性,不過藉助 /proc 其實也可以得到不少資訊。
  • 對 socket I/O, 甚至只是 IPC(程式間互動)的應用場合也較不適合
  • 對採用 library 的應用程式,當然無法直接用 shell script 來處理
  • 最後,若您不想公開源碼時,就別選 shell script! 不過若要把 shell script 變成 binary code 是不是可能呢?或許有人會提供像 php, python, perl 等 scripting 語言的 compiler, 但是我覺得,那會失去不少 scripting 的意義。

0 意見: