这里列举一下在基物实验数据处理中用到很多次的脚本，
使用的时候需要把每个函数单独保存在一个文件中
可以使用如下查询命令查看使用方法
help function_nameLinux-Unix备考
一、发展与历史
体系结构包括指令集，存储组织，I/O，总线结构。写到这里的时候真的觉得一切都值了。
1.1 操作系统迭代
一开始的操作系统是批处理式的。批处理的意思就是把一堆任务集中到一起，然后一起处理，这样的好处是实现了初步的流水线化。但是计算机要读取任务，要通过磁带，而磁带上的内容，要通过读卡器读取卡片（可能就是一堆打着孔的硬纸板吧）写到磁盘上，如果读一个任务写一个磁带，然后读一个磁带，处理一个任务，这就太慢了。所以就考虑可以先用读卡器将一堆任务的卡片都一起读到磁带上，然后一起把这些磁带上的任务处理了。这就是所谓的批处理。那么这个时候，操作系统的主要作用就是自动地一个任务一个任务的完成。
之后就变成了多道程序设计。尽管我们把写磁带这个功能给分割开来，让计算机可以安心处理磁带上的任务，但是计算机依然是需要读取磁盘上的内容的，这段 I/O 所占的时间 CPU 是不会工作的。为了把这段时间利用起来，我们可以考虑在内存中存放多个任务，这样当有一个任务在进行 I/O 的时候，CPU 可以去运算其他任务，这就是“多道程序设计”。所谓的“多道”，就是说在内存中存在多个任务。可以看作是在内存空间上实现了并行。
操作系统-用户进程
一、Makefile
这个 Makefile 要比之前的文件夹中的 Makefile 更加复杂，是因为之前的文件夹都是对操作系统特定部分的一个编译指导，所以基本上是实现的功能就是“对应的 C 文件和汇编文件编译成目标文件”这一个功能，最后合成一个整体。但是 user 的 Makefile 指导的是多个用户程序的编译，最后生成的是多个用户目标文件，同时还需要给每个用户文件装备上库目标文件。
首先先补充一下 makefile 的一些知识
自动化变量
$@表示目标（target）文件，就是冒号前面的那个文件$^表示所有的依赖文件，就是冒号后面的那一堆文件$<表示第一个依赖文件，就是紧挨着冒号后面的一个文件$*这个变量表示目标模式中%及其之前的部分。如果目标是dir/a.foo.b，并且目标的模式是a.%.b，那么，$*的值就是dir/a.foo。
操作系统-文件系统
一、总论
1.1 直观感受
这一章虽然名义上很简单，但是我个人觉得真的很难，其难度是要远超于 lab3 和 lab4 的。对于 lab3 和 lab4，其难度主要集中于复杂的函数调用关系上，如果理清了函数调用关系，会发现难度就很容易弄清了，而理清函数关系只要通过认认真真的看代码，整理就可以办到。而 lab5 的难度在于理解操作系统的设计，这种理解不是代码层次的“一个函数是调用了哪些函数，传了哪些参数？”这一类的问题，而是 MOS 是怎样设计的，为什么要这样设计的问题。这些问题在 lab4 中也出现了，比如异常处理的微内核设计。
1.2 文件系统微内核
这一章的微内核与 lab4 的异常处理的微内核是两个东西，这是最重要的一点。微内核设计都强调将原本属于操作系统的一部分功能分配出来（比如说异常处理，文件系统），分配给用户进程完成。在 lab4 中，微内核设计是把异常处理的功能分出来，让每个进程都具有异常处理的功能（以库函数的形式）。但是在 lab5 中，微内核设计确实将文件系统的实现分了出来，但是并不是配置到了每一个用户进程上，让每一个进程都有文件系统的能力，而是专门开设了一个用户进程专门提供文件系统的服务（这也是这个用户进程的大部分实现文件都被放置在了 fs 文件夹下，而不是 user 文件夹下的原因），而其他进程想要获得文件系统的服务，就要与这个特殊的用户进程进行通信，就好像之前与操作系统进行通信一样。
面向对象-JML
一、总论
第三个单元作为从第二个单元的心态考验中解放的一个单元，很容易让人先入为主的松了一口气。这个单元干的事情确实要之前两个单元要少，这是因为其实我觉得 OO 最体现思维的“架构设计” 部分被 JML 剥夺了（这么说并不严谨，之后分析）。导致确实这个单元的任务重心并不在完成作业本身，这是大部分人呈现的情况。
但是人的精力总是一定的，没有被写 OO 本身浪费掉，就会被其他事情浪费掉。而这个单元恰恰有两件浪费精神的事情。一件是去优化算法的复杂度，，一件是去做测评。
关于算法时间复杂度的优化，我个人感觉是一种“被动卷”。这种卷带来的不好受并不是像前两个单元，因为简化一个表达式，或者改一种电梯策略的“主动卷”。而是一个必须参与的“默认卷”，一个很死板的东西。从三个方面分析：
- 代价过大，比如说如果没有进行算法优化，不是没有性能分，而是直接被人 hack 掉，虽然分数确实不多，但是太令人恶心了。
- 毫无美感，所谓的优化就是内部维护一个中间变量，不涉及算法（当然图算法也算用到了，但是最恶心的是其他的维护变量）
- 与
JML无关，哪怕是图算法或者并查集，很精妙，但是跟JML没有关系，JML是用于规范代码的行为的，算法是用来改善代码行为的。类似于一个是法律，一个是经济，要研究法律（JML），探讨的应该是“张三与 20 个老婆结婚但是都不领结婚证，算不算重婚？”这一类明显需要细细甄别的问题，而不应该探讨“如何让张三与 20 个老婆结婚但不领结婚证”这个问题（这是一个经济问题（算法））。