“究竟在干什么”是一系列关于软件开发过程中背后运作原理的文章，每一篇文章旨在讲解一些在日常编程实践中常见但可能并不为人所熟知的技术细节，抛砖引玉，期待激发读者朋友的更多思考。

如何在shell中比较大小？

如果在搜索引擎中搜索“shell 比较”，那么得到的结果基本上都在告诉你要写[ blablabla ]这样的代码

例如，如果想知道当前的UNIX时间是否已经以16开头，可以用下列的shell代码

1
2
3
4
5
6
7

#!/bin/bash
ts=$(date '+%s')
if [ "${ts}" -gt 1600000000 -a "${ts}" -lt 1700000000 ]; then
    echo '当前的UNIX时间戳已经以16开头啦。'
else
    echo '当前的UNIX时间戳还没以16开头哦。'
fi

当我写这个的时候，date '+%s'的值为1587901648，所以运行后走的是else的分支。

除了用-gt表示大于之外，还有各种各样的其它比较运算符，例如下列的四个运算符

还有一些“测试”类型的运算符，例如

[是shell的语法么？

大部分写shell代码的人或许会认为，[]是shell语言用于实现一系列的比较操作的特殊语法。但实际上，[]并不是一个语法——[是一个独立的命令行程序，]则什么都不是，仅仅是一个普通的字符。

在bash中使用which命令可以看到[的真面目

[是一个独立的程序，对，你没有看错（鲍尔默脸）。而且[有它自己的man文档

在man文档中出现了另外一个命令test，它和[的功能是一模一样的。或许test是一个“yet another [”？真相却更简单一点——test和[是同一个东西

[源代码的二三事

可以在GitHub上找到[和test的源代码，代码很短，稍微读一下可以发现不少有意思的地方。

众所周知，如果在shell代码中使用[做比较运算，必须写上对应的右方括号]。但既然[是一个普通的外部程序，那么这个匹配括号的检查显然不会是shell来做的——没错，[自己会检查是否有写上相应的右方括号，这一段逻辑在源文件的main函数开始不久就出现了。

这个检查只有在程序被以[的名字启动的时候才会生效，所以test 1 -eq 1是不需要写括号的。

其实除了上文中给出的那些比较和测试运算符之外，[也支持复杂的逻辑运算表达式，比如文章开头的示例代码中的-a就是逻辑与的意思。在代码的注释中还贴心地给出了所接受的参数的BNF

而解析参数的过程则是一个手写的递归下降语法分析器，在源代码中可以找到与上面的产生式对应的多个函数：oexpr、aexpr、nexpr、primary，以及binop。

由于在shell语言中，0表示逻辑真，而1表示逻辑假（与C语言相反），所以在main函数中，如果发现传入的第一个参数为感叹号（!，表示逻辑取反），则将oexpr的调用结果直接返回，否则需要将结果取反后再从main函数中返回——给操作系统。

shell真的不原生支持比较？

尽管在bash中，[的确是作为一个外部程序存在的，但在zsh中却相反

而且，即使是bash也并非完全没有原生的比较操作——此处需要召唤[[。[[是shell的保留字，它是一个less suprise版本的[，在Stack Overflow上有不少关于它的问答值得一看：

1. https://stackoverflow.com/questions/3427872/whats-the-difference-between-and-in-bash
2. https://stackoverflow.com/questions/669452/is-double-square-brackets-preferable-over-single-square-brackets-in-ba

第二个链接的回答中还给出了一个值得一看的、关于bash中的“测试”功能的指引，其中甚至提到了

It can produce surprising results, especially for people starting shell scripting that think [ ] is part of the shell syntax.

后记

不得不承认，本文标题党了一把，shell还是自身就具备比较大小这样的功能的。

“实战Elisp”系列旨在讲述我使用Elisp定制Emacs的经验，抛砖引玉，还请广大Emacs同好不吝赐教——如果真的有广大Emacs用户的话，哈哈哈。

序言

我要编写一个Elisp函数，其核心逻辑涉及到替换字符串中一个符合某种模式的子串。举个例子，字符串为"[2020-02-15 Sat 14:19]《业务逻辑需要关心同步还是异步吗？》"，需要替换的是其中的[2020-02-15 Sat 14:19]。

这个由日期和时间组成的前缀在每一次我按下C-c c t的时候会自动产生，因为在org-capture-templates中就是这么设置的

1
2
3

(setq org-capture-templates
      '(("t" "Todo" entry (file+headline "~/Dropbox/gtd/inbox.org" "Tasks")
         "* TODO %U%?\n  :PROPERTIES:\n  :CREATED_AT: %U\n  :ID: %(uuidgen-4)\n  :END:")))

更具体一点，它们产生自其中的转义序列%U（详情可以参见org-mode的文档Template expansion）。

经过一番不是特别仔细的搜索后，我决定用string-match和replace-match函数来完成上述替换子串的需求。

然后便闹了两个乌龙。

string-match不支持扩展的正则语法

为了匹配形如[2020-02-15 Sat 14:19]这样的字符串，我的直觉便驱使我写出了这样的正则表达式

1

"^\\[\\d+-\\d+-\\d+ \\w+ \\d+:\\d+\\]"

在Node.js或其它支持Shorthand Character Classes的语言中，上面的正则表达式是可用的。

但是Elisp偏偏不是这样的语言！（Elisp所支持的正则表达式语法可以参见这篇文档）因此，在Elisp中只好用下面这个正则表达式

1

"^\\[[0-9]+-[0-9]+-[0-9]+ [A-Za-z]+ [0-9]+:[0-9]+\\]"

虽然Elisp不支持Shorthand Character Classes，但它确实支持Character Classes，但这样写出来的正则表达式更长了

1

"^\\[[[:digit:]]+-[[:digit:]]+-[[:digit:]]+ [[:alpha:]]+ [[:digit:]]+:[[:digit:]]+\\]"

我猜你宁可写前一种对吧。

replace-match不返回新字符串

这货是用来修改一个buffer中的内容的……

一种Workaround

最后我根据需求的实际情况，综合使用string-match、substring，以及format实现了替换子串的功能

1
2
3
4
5
6
7
8
9
10
11
12
13

(defun lt-org--starts-with-timestamp-p (text)
  "返回T或NIL表示输入字符串是否以一个inactive timestamp开头。"
  ;; Emacs的正则表达式并不支持如\d和\w这样的类，所以要写成[0-9]和[A-Za-z]的形式
  (string-match "^\\[[0-9]+-[0-9]+-[0-9]+ [A-Za-z]+ [0-9]+:[0-9]+\\]" text))

(defun lt-org--delay-timestamp (text new-timestamp)
  "用NEW-TIMESTAMP替换TEXT中的inactive timestamp。

如果TEXT没有以inactive timestamp开头，则直接添加NEW-TIMESTAMP。"
  (format "%s%s" new-timestamp
          (if (lt-org--starts-with-timestamp-p text)
              (substring text 22)
              text)))

过了很久后，我终于发现了在Elisp中做字符串替换的正确做法……

正确答案

只要用replace-regexp-in-string函数就足够了

1

(replace-regexp-in-string "^\\[[0-9]+-[0-9]+-[0-9]+ [A-Za-z]+ [0-9]+:[0-9]+\\]" "abc" "[2020-02-15 Sat 14:19]《业务逻辑需要关心同步还是异步吗？》")

结果为"abc《业务逻辑需要关心同步还是异步吗？》"，替换很成功。

后记

如何在浩如烟海的知识（搜索引擎、在线文档）中找到自己需要的东西，也是一门学问啊。

序言

受疫情影响呆在家中的这段时间里，我收尾了《Clean Architecture》。这本书给了我许多新知识和启发，包括本文的中心论点——数据库schema不是CRUD服务的一切，也是在读书过程中想到的。在书中，作者的原话是

But the database is not the data model

它出现在书中第六部分《Details》的第一个章节中。作者认为，从架构的角度来看，数据库不是一个实体而是一个细节，不足以成为架构中的一个元素。他甚至打了个比方：数据库对于架构而言，就好像门把手对于房子一般。并且，作者进一步澄清了他的观点：他口中所说的数据库，不是指的数据模型。应用内的数据结构对架构而言至关重要，但数据库并不是数据模型。

这不禁让我回忆起了自己早期写设计文档的套路。

在我的从业生涯早期（说得好像我从业很久了一样），每当需要开发一个新的Web服务时，必须先写一份简要的设计文档，向上级清楚地表达我的实现思路，包括：

1. 如何与其它服务协作完成产品提出的需求；
2. 服务的接口描述；
3. 数据的存储结构；
4. 关键的算法等。

那时候的我会先考虑数据的存储结构，然后定义接口，最后才是与其它服务的协作。这些早期设计文档的其中一个特点是：接口的响应格式，与数据的存储结构是相同的。

比方说我要设计一个网上商城的订单服务，可能会提供如下查询特定订单的接口

1

GET /order/:id

其响应格式可能如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

{
  order: {
    id: 'F122663A-A5DC-451A-9B79-92DCE2EE41F1',
    price: '100.00',
    products: [
      {
        id: 1,
        name: 'MacBook Pro',
        price: '19999.00'
      },
      {
        id: 2,
        name: 'iPhone',
        price: '6999.00'
      }
    ]
  }
}

为了保存这种“不平坦”的对象，将会用MongoDB作为存储——除了文档的主键_id之外，其它字段在接口和存储之间一一对应。

不仅仅是响应格式，在这个Web服务内所操作的也是同样结构的对象。用MongoDB Node.JS Driver获得的订单恰好是一个JS对象，它与collection的文档有着一模一样的结构。之后这些对象会在代码内到处流通，不加修饰地使用。定义了数据库schema（就算是用MongoDB也有一套脑内的schema）后，其它的一切也就跟着确定了。

业界甚至有工具可以直接从数据库得到API，比如postgrest。

很多时候，数据库schema成了一个应用内事实上的数据模型。但是，即便它们可以偶然一样，也不要认为它们总应该一样。

适合存储，不一定适合计算

以MySQL为例，在CREATE TABLE语句中某一列的类型实际上决定的是存储时分配的空间的多少。但适合存储的类型，并不一定也适合业务逻辑的运算。

比如说，要在MySQL中存储“开关型”的数据，即诸如“是否启用”或“是否已支付”这样非此即彼的状态时，通常定义为TINYINT类型，用0表示逻辑假（“未启用”和“未支付”），1表示逻辑真（“已启用”和“已支付”）。但对代码而言，比起用数值类型，布尔类型才是更恰当的选择。尤其是当所选择的语言并没有将0与false、1与true等价起来的时候——在Common Lisp中，(if 0 1 2)的求值结果为1。

适合计算，不一定适合存储

通常数据结构在内存中比在磁盘上要容易表达得多，所以代码中使用的数据结构会比数据库中存储的要灵活不少，这同样造成了两者的不匹配。

以我自己开发的提醒工具cuckoo为例，应用内有两种对象：任务和提醒。任务描述了要做的事情，提醒描述了在什么时候该告诉用户。显然，提醒是一个依赖于任务的弱实体。在cuckoo的代码中，任务是Task类的实例对象，有一个名为remind的成员变量存储着提醒。

但这样的结构不方便存储在MySQL中。遵照关系型数据库设计的第一范式，任务和提醒分别被存储在t_task和t_remind表中，两者通过t_task.remind_id联系起来。

当然，也可以在一开始就用MongoDB来存储这些数据（甚至可以用对象数据库？不过我没玩过）。尤其是cuckoo只是一个小玩意儿，MySQL和MongoDB都足以胜任。但作为一名有理想的程序员，在做设计的时候，不应该让低层细节过分干预高层策略。（在《Clean Architecture》中，越是接近I/O的越是low-level，反之则是high-level。）

面向业务逻辑，而非存储结构

业务逻辑和规则才是一个服务的核心，应该把更多精力花在实现业务逻辑的数据结构和算法上。

以网上商城中常见的优惠券功能为例。优惠券服务所管理的优惠券往往有着各种效果、条件，以及限制。为了保持灵活性，优惠券类（下称Coupon）的实例对象中会有三种接口类型的成员变量：

1. Effect类型的变量effect，负责实现优惠效果的计算逻辑；
2. Condition数组类型的变量conditions，负责实现使用条件的检查逻辑；
3. Restriction数组类型的变量restrictions，负责实现使用限制的检查逻辑。

三个接口可以有各种各样的实现——定额减免、折扣减免、某年月日前可用、不可用于电子产品，等等。如此，优惠券功能具备了极大的灵活性，业务可以随心所欲，产品可以为所欲为，老板数钱数到手软，公司业绩蒸蒸日上。

那么如何存储Effect、Condition、Restriction、Coupon类的实例对象呢？没有唯一的选择，既可以存储在MySQL中，也可以存储在MongoDB中，或者别的什么数据库中。不管这些数据最终如何持久化，都不会影响作为高层策略的优惠券业务逻辑。反过来，如果在代码中处理的不是类、接口，以及实例对象，而是直接从数据库中取出来的、贫血模型的行（或文档），处理起来就不是很优雅了——可以预见 ，代码中会充斥着许多的if-else判断逻辑。

数据库只是帮忙从磁盘中读取数据的软件，它的schema不应该直接成为应用的数据模型。

Interface Segregation Principle

不应该在HTTP接口的响应中直接暴露数据库的schema。

不说别的，光是数据库schema与接口规格所使用的命名规则就足以造成差异了。也许在MySQL中用snake case命名一列，却又在HTTP响应的JSON对象中用camel case命名字段。

此外，除非这些接口仅仅实现增删查改、没有任何的业务逻辑或规则，否则一个服务更应当提供与业务需求恰好契合的接口。仍然以上文的优惠券服务为例，尽管内部可能Effect、Condition、Restriction、Coupon等诸多概念，但煮不在乎用户不在乎，他们只想看到用人话说出来的优惠券效果以及使用规则——用户甚至不关心条件和限制有何不同。

如果优惠券服务直接将数据库中的行（或文档）序列化成JSON返回给调用者，会导致封装的泄露。每一个查询优惠券的调用方，都必须了解优惠券的内部表示形式，必须知道效果由effect描述、用券后的订单金额是多少、conditions中有关于过期与否的信息，等等。每增加一个优惠券服务的使用者，就相应地增加一套描述这些内容的代码。甚至当优惠券服务自身重构的时候，也许牵连到众多的调用方。

如果直接将存储结构暴露给调用者的话，又何必再做一个Web服务呢。

切勿矫枉过正

的确存在这样的例子，数据库schema、数据模型，以及HTTP响应结构三者相同。这是因为比起维护数据库schema与数据模型的转换规则，以及DTO与数据模型的转换规则而言，在领域代码中直接使用数据库schema来表达数据模型的成本更低一点。尽管数据库schema不是Web服务的一切，但很多时候可以因地制宜地妥协一下。

“实战Elisp”系列旨在讲述我使用Elisp定制Emacs的经验，抛砖引玉，还请广大Emacs同好不吝赐教——如果真的有广大Emacs用户的话，哈哈哈。

半年前我在这篇文章中展示了在Emacs中查阅笔记的效果——用emacs-request请求ElasticSearch查询关键字、基于helm以下拉菜单的方式展示查询结果的标题（即问题），最后打开浏览器查看笔记内容。稍加使用就发现一些不足之处：

1. 需要离开Emacs打开浏览器。我更希望能在Emacs中查看；
2. ES的响应内容为JSON，要快速地辨认出question和answer字段比较困难；
3. 一个问题的答案往往是多行的，但在浏览器中answer字段是以一行的形式展示的，不利于阅读。

为了解决这些问题，我实现了一种新的查看笔记内容的方式。

改良后的效果

尽管我最近开始用VNote做读书或读在线文档的笔记，但更多的时候，我把经验型知识都记录在一个名为my_note的Git仓库中。这个仓库中有许多.org`文件：

1. TeX.org，记录与LaTeX相关的问题和解决方法；
2. asm.org，记录的是与编写汇编语言程序相关的问题和解决办法；
3. cl.org，记录的是与编写Common Lisp代码相关的问题和解决办法；

这些内容被我称为FAQ。尽管不同的文件记载着不同方面的内容，但它们的格式是一致的：

1. 每个文件都以org-mode的语法书写；
2. 文件中只有一级条目，没有嵌套；
3. 每一个条目的标题就是一个问题的表述，下方的文字则是这个问题的答案。

A picture is worth a thousand words

这些问题都比较常见（不然怎么叫FAQ呢——也许上图的不算常见吧），回过头来查找的机率很高。显然，在纷繁复杂的文字中凭肉眼寻找关键字是低效的，即使是祭出grep，用正则表达式这样的大杀器来查找也不是特别称手——因为并不知道怎样的正则表达式可以匹配到寻找的内容——也许多写了关键词，也许少写了，也许顺序不对。

对于搜索这类非结构的文字资料来说，全文检索是一个更好的选择，因此，我是把这些内容丢进ElasticSearch里再查找的。

解析并导入到ElasticSearch