CITA 的命令行工具（四）

今天是 2018 年的最后一天，本来按照惯例，应该是一篇 2018 年的总结，但我发现答应要写的命令行最后一篇还没有完成，虽然早已拖了两个月，但是这一篇还是不要拖到明年去了，今天就把这终结篇写完。

命令行 or 交互式

在 cli 这个项目的最开始，我的初始目标仅仅是一个命令行工具，用来方便 CITA 的开发。当第一个小版本写出来之后，发现由于 CITA 的 rpc 接口过多，对应的命令也过于繁杂，如果没有自动补全帮助，甚至对于我这个开发者来说，这个东西也是很难用的，而如果要根据命令写一套对应的自定义补全 bash/zsh/fish 脚本，那怕是要了我的老命。于是一方面在社区中寻找是否有能够自动生成的工具，另一方面，做成交互式命令行工具的念头在脑海里慢慢形成。

经过一番简单的查找，最开始 linefeed 这个项目走进视野，虽然这个项目相对来说比较早期，但是对当时的 cli 项目来说已经足够用了。于是，立刻研究一番，并引入 cli 中，经历了两个版本的迭代，发现了 linefedd 存在的一些小缺陷以及一些不足的地方，在 0.19 版本发布前夕，用 rustyline 替换掉了 linefeed，对用户来说，这几乎是无感知的，除了多了几个选项，比如命令行的命令是 vim 模式还是 emacs 模式，补全行为是 list 还是 circular，还有补全的东西被染色了，诸如此类的小改动。这些新的选项都是由 rustyline 这个交互式命令行库本身提供的，我只是对其做了一点点简单的封装导出工作。

在拥有交互式模式的情况下，cli 为什么依然保留其命令行的功能呢？这个问题其实很简单，对于人来说，无提示的命令行模式确实难用，但是如果将 cli 作为一个测试工具，在 bash 或者是各种编程语言中进行调用，那么命令行模式的难用问题是不存在的，并且这种默认输出 json 格式的命令行对调用程序是友好的，为了让其承担这样的责任，命令行模式并没有因为交互式的存在而删除，反而所有命令的调用与交互式几乎是一致的（除了几个全局变量）。从能够被其他程序调用的方向来看，这样的选择又是对人友好的。

是否完全记录历史命令

在最开始的版本里面，所有的输出的命令，都被忠实得记录在 ~/.cita-cli/history 里面，通过这个文件实现了类似于 bash 一样的查询/翻阅历史命令的功能，但是在后续几个版本，默认行为进行了修改，强制将能够解析成私钥的字符串都在保存之前删除掉了。这个行为在当时考虑的是，这个命令行如果记录下了用户使用的私钥的明文，会有重大的安全风险，所以强制删除掉了能够解析成私钥的任何字符串。对于 cli 的用户来说，包括我在内，在强制执行这个功能的几个版本里面，都非常难受，因为，私钥在每一条命令都需要重新输入，哪怕是在调试阶段，令人烦不胜烦。而在最近的几个小版本里面，我又偷偷把这个强制功能改成了可选打开的模式，增加了一个 switch --save_private 开关，默认是关闭的，如果用户将其打开，那么 cli 就会保留输入的所有命令，而不是删除私钥进行保存。也就是将安全问题交给用户自己选择，不过对于我这个用户来说，我几乎都会打开这个开关，方便操作。

Get、Set 及默认行为

在 0.18 版本前夕，在 cli 中添加了一个非常小的功能，内置了一个类似于 redis 的 get、set 的缓存表，并且将每次于 CITA 交互的 Result 默认保存在该表的 result 这个 key 中，每次查询都会覆盖掉之前的结果。而在这个缓存表中保存的所有值都可以通过类似于 bash 字符串替换的语法 ${key} 在命令行中进行替换 value 值，方便人存储一些临时的值在缓存中，而不需要每次输入，同时因为 rpc 的返回结果也在缓存中，如果需要利用到上次交互的结果，也可以很方便的通过字符串替换的方式进行读取。这个功能在发版时只是提了一下，可能绝大多数用户都不了解这个功能，一个简单的缓存 hash 表加上正则匹配。

主体功能

剩下的功能，都是主体功能，为了方便与 CITA 交互而写，包括最原始的 rpc 接口，对系统合约的包装，ethabi 的包装，特殊命令的封装，算法的封装。这些东西庞杂散乱，需要有一个东西能够更清晰友好地呈现给用户。比较遗憾的是 cli 并没有发布到 crate.io 上面，因为算法库的依赖是 cita-common 内部的分支。

宣布进入维护期之后的两个月

在两月之前，我对外宣布 cli 这个项目正式进入维护阶段，新功能的开发进入无限延后，只对 CITA 某些更新以及 Rust 本身的更新迭代进行同步更新。这两个月，我也几乎没有对这个项目做更多的关注和更新，很欣喜的是，从 github 的数据来看，实际上这个项目被使用的频率并没有明显的下降。

与此同时，不止一个人对我进行提议，从 cli 这个项目中抽一个交互式命令行快速搭建的框架出来，cli 这个应用本身过于小众，但是将框架抽出来之后，可使用的场景就非常广泛了。但是，这个念头其实从我脑海一飘而过，并没有停留，因为从最本质来看，cli 应用这个项目，仅仅是对 rustyline 和 clap 的有机结合，说破天去就是写了一个 clap 的命令行搜索放入 rustyline 对应的接口中，并将搜索做了模糊匹配处理，真正的交互式功能是 rustyline 提供的，命令行解析功能是 clap 提供的，如果将这两个库结合起来加上一个命令行搜索做成一个新的快速搭建命令行工具的库，我觉得这并不是一个很好的选择。

而这两个月中的一大部分时间，我都在折腾 libp2p，直到昨天，我确定，自己写的 p2p 库目前在小数据测试下，稳定性应该不存在很大的问题了，34 个客户端与一个 server 连接，加密通信的情况下，简单的持续 12个小时小数据交互，并没有出现任何异常。这个库后续还需要添加很多东西，我也期待它的稳定，让我们拭目以待。