何時不要用 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 的意義。