重新学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的潜力作为对照；实现最大限度地减少重复劳动，推进“办公自动化”，从而有更多的时间留给我们……玩游戏