2018.12.19 看shell 有感

最近再看一本书，叫《Linux shell 脚本攻略》，英文名带cookbook，不知道算不算系列图书之一。

这篇文章，我无意把它写成笔记，也无意总结成方法论，只是说说自己的想法。

语言学习

我在早期看过一部分鸟哥的书，整体看下来，有点用，但是废话也有点多。而且基本都忘了。

最近感觉自己要用脚本了，每当自己想写总是觉得有些东西不是很清楚。最终还是决定补充下脚本的基础概念。就找书看了下。

我个人有个习惯，学一种语言，首先要了解语言产生的历史背景与演变规律，诞生是为了做什么事，解决什么问题。每个时间段发生了什么事，语言特性变成了什么样。最终演变成了什么样，大家都怎么用。

当然不会像上面说的那么全吧，主要针对的是自己不懂的点，这些点多半都是历史遗留的结果。了解了这些背景才会清楚是怎么回事。

然后再去了解语法特性，了解最基础的规则是怎么回事。有了以上的最基础的概念之后，才能有学的感觉。如果不看看shell的书，没有人能够明确的跟你说，哪个是入参，哪个是返回值。man手册只是命令的说明，完全没有说理论，也就是没有tutorial，初学就推荐看man的人都不太行。

再接下来就是看基础类库，看常规的操作中都提供了什么功能。这些功能也代表着语言的设计思路。比方说java提供了多种不同的map，适用于各种场景。每个场景都有自己的使用思路。这是类库设计中蕴含的东西。说白了就是作者希望你怎么用。

当然除了这些之外，其中有一个非常让人误会的东西就是bash和shell，还需要区分shell和bash所指的东西。类UNIX系统用的交互都是shell，其中linux默认用的是bash，当然有兴趣的话还可以换成别的shell，如oh my zsh。反正就是简称为xxsh的各种东西。在wiki中第一句话也是这么写的

Bash is a Unix shell

学习感悟

从目前学习了两章的内容来看，bash完全就是一个处理字符串的东西。运算有，不强，麻烦。剩下的就是各种操作系统的功能性的东西了。

bash确实就是个脚本，体现在规则很松散，各种定义部分不是很明确，几种不同的字符串。就像rename命令还融合了prel 的语法，设计就非常的随便。一旦变得随意起来，就不健壮了，很容易用出问题，很难重用。（美刀+转义+各种引号，层级一多就晕，比递归还难理解）

它的模型就是一个，命令端交互的命令，打的字或者是其他什么作为输入，然后用command调用命令，命令运算，然后输出到当前的控制台或者是别的地方。输入被称作stdin，还有些特殊的需要xargs（还没太看懂）或者exec。

我一直有一个这样的感觉（并没有深挖历史去找证明），感觉这个shell在设计的时候，应该带有很多个人随意的东西，然后流行起来之后，缺点会逐渐放大，没有经过精心设计的东西，会出很多问题（鬼知道有多少人在给这个东西擦屁股）。

在bash的相等之类的命令中看到了eq和-eq之类的还有大于小于的文字，感觉jsp这类东西就是从这里面抄的。他们背后的思路是一样的，用代码来处理文本，对文本进行替换格式化操作。可能是因为已经有类似的了，就直接拿过来 借鉴 了

类似的还有eval，从我记忆的时间线上看，JS也有类似的，应该就是从bash抄的吧，又或者是有共同的祖先。

bash的用途

linux普及度这么高，各种各样的发行版，上面默认搭载的东西，一时半会换不了的，所以bash在某种意义上讲，是很难死的。当然也不是说它有多烂，毕竟前辈都铺了这么多的路了。再来一个也不好做。

所以需要明确的是什么时候应该用shell

1. 只能用这个，不能用别的（进系统操作啊，查状态啊，没图形界面那就只能用这个）
2. 只有用这个方便，用其他的脚本不方便的时候

当然，shell这种东西，并不是一无是处了，算个md5啊，在windows上面，多半要找软件来解决，bash一句话的事。筛筛文本啊，也很容易做。

md5sum xxxxx

总结来说，就是要了解什么东西适合shell干，什么东西不适合shell干。在现在这个时代，很多东西都有替代品，不过仅仅是能替代，但是能做到什么程度就不好说了。每种语言都有擅长的部分。

为什么网上总有人写一点点bash

很多程序员不太会操作linux，也不懂bash的设计，他们只是会照着敲命令，然后把敲的命令总结下来，备查。

我一直觉得这是十分可怜的行为。在我学了接近2年编程的时候，我似乎领悟到了这样的一点。现代编程需要的能力是领悟设计的模型的理解力，某些人设计出这个东西，按照什么模型设计的，希望使用者如何使用，如何扩展。模型中的对象之间如何交互。这些东西才是程序员应该了解的。

一旦理解了模型的设计，那么使用起来就会非常的游刃有余。错误的使用不是不可以，可以，但是结果不会好。就像用水管也能盖出来房子，但是不会让人舒服的。

再一点，很多模型的设计是非常常规的，用了很多常用的概念。任何一个称职的程序员看到都懂。

模型的背后其实是常规的通用的做法，也就是所谓的道，换个字说叫渔。

顺便吐槽个前辈

这本书，说实话，并不厚，但是内容不少（至少前两章是），很多命令都要想想才会明白怎么回事。比代码书看着要费劲。因为脚本嘛，设计目标是随手用，很多时候尽可能的短，短到不知道怎么回事。

我就找前辈问问，哪些可以先略过。结果他tmd说，他基本都用过，建议我都看一下，我tm。我事后才反应过来，我问的问题是那些常用，哪些不常用。它的回答却是那些用过，那些没用过。都一样经常用怎么可能呢？没多少人一直在做java的图形界面。

这个工作十来年的前辈也不是个明白人啊。（叹～