重新學Bash

  今天想寫個簡單的bash腳本，打開編輯器後，發現已經忘了……
  自從離開了實驗室以後，我基本上就沒有在linux環境下開發了。以前寫C程序，在配合上一些bash程序，處理大量的實驗數據，感覺很爽。工作後，主要在windows環境下，由於習慣原因，偶爾會用一些batch批處理，不過batch的功能和shell相比還是有不少差距……最近終於裝了cygwin，正好想搞些批處理，於是回憶起bash來。結果引用變量忘了${}，數組變量寫成了C語言定義的形式，for()裏面卻不知道咋寫……
  雖然說bash我已經相當長一段時間沒接觸了，但是我覺得這不應該是造成遺忘的主要原因。什麼微積分啊電磁學啊我也好久沒用，不過基本公式還是記得；C++也好久沒寫了，現在寫個簡單的帶模板的類應該還是沒問題的。bash語法這些這麼基本的都忘了，我想最主要的原因是當時沒有系統地學、打好基礎，而是上網找現成的程序範例去改，遇到問題可能會查查reference manual之類，沒有再進一步去研究。儘管這樣上手比較快，出效果也快，不過一旦不用了遺忘得也快。所以，我翻出以前下載的電子書，還有GNU Bash Reference Manual，在寫好了現在需要的那個腳本後，從頭開始看。
#!/bin/bash
#batch, encrypt 256 files(00-FF), and append the content of outputfile as hexademical text to a file

InputFile=PlaText
OutputFile=CipText
Stdin=Key.txt
Result=CipSet.txt

Index=(0 1 2 3 4 5 6 7 8 9 A B C D E F)

for(( i=0; i<16; i++ ))
do
    for(( j=0; j<16; j++ ))
    do
        #cmd fmt: cryptest e inputfile outputfile; obtain key by stdin
        ./cryptest e <${Stdin} "${InputFile}_${Index[$i]}${Index[$j]}.txt" "${OutputFile}_${Index[$i]}${Index[$j]}.txt"
        #64 bytes per line, no radix
        od -t x1 --width=64 --address-radix=n "${OutputFile}_${Index[$i]}${Index[$j]}.txt" >> ${Result}
    done
done
  後記：整理好小腳本後，回想起當初開始學習寫shell腳本的原因：那時候用C/C++進行些物理模型計算，通常原始的計算結果會再進行好幾種稀奇古怪的數學計算分析，爲了方便切換分析方法，避免經常重新編譯以及重複計算，通過分割開幾個程序，保留了中間原始結果，用重定向把整個過程連起來；後來發現那些模型有好多參數要經常反覆改，程序用傳命令行參數的方法比較方便，把標準輸入輸出留給數據；而且在shell裏處理輸出文件名比在C/C++程序裏方便，把標準輸出重定向到文件，文件名可以簡單地連上模型參數和系統時間，避免混亂。因此，當我需要實現分析某些參數的改變對模型的影響時，就可以在bash腳本里寫個循環，自動“批處理”模型的計算和分析，然後可以往服務器一扔讓它慢慢跑。這樣對比起所有工作都用一個C/C++程序實現完成而言，既保留了操作d的簡單：輸入執行腳本文件就OK了；又增加了靈活性：模型計算或者分析可以方便地獨立修改升級甚至替換。這樣的設計在可執行文件層面有效地分割了工作控制和模型算法，對以後的維護也有不少的裨益。我想諸如測試腳本、遊戲腳本等腳本的設計原則之一就是這個，減少系統的耦合，提高開發的效率。
  說起來目前我對bash的應用還停留在"批處理"。在工作中我偶爾需要對一些採集的數據進行簡單的處理或分析，周圍的牛人一般都用matlab……一來，我不會matlab；二來，有點殺雞用牛刀的感覺；第三，還有很多機器沒有裝這個重型武器。因而我又使出慣用的“批處理”帶參數小程序技倆。儘管batch批處理的功能感覺和bash比起來還是差多了，可能我還得仔細研究下吧。總之，這種模式未必是最好的，不過在找到更好的模式之前，我會學習bash，同時充分發掘batch的潛力作爲對照；實現最大限度地減少重複勞動，推進“辦公自動化”，從而有更多的時間留給我們……玩遊戲