Command-Line

一、创建一个命令模块1、package.json { "name": "@uad/nat-cli", "version": "0.0.2", "description": "Demo", "main": "index.js", "bin": { "artisan": "./src/artisan.js" }, "scripts": { "test": "echo \"Error: no test specified\" && exit 1" }, "repository": { "type": "git" }, "keywords": [ "CLI" ], "author": "chunrong.liu", "license": "ISC", "dependencies": { "shelljs": "^0.8.3", "yargs": "^13.2.4" }}2、src/artisan.js #!/usr/bin/env noderequire('shelljs/global');var argv = require('yargs').option('n', {alias : 'name',demand: true,default: 'tom',describe: 'your name',type: 'string'}).usage('Usage: hello [options]').example('hello -n tom', 'say hello to Tom').help('h').alias('h', 'help').epilog('Copyright 2019').command("morning", "good morning", function (yargs) {echo("Good Morning");var argv = yargs.reset().option("m", {alias: "message",description: "provide any sentence"}).help("h").alias("h", "help").argv;echo(argv.m);}).argv;console.log('hello ', argv.n);console.log(argv._);二、使用方法1、将命令模块通过npm link进行全局注册后，即可在命令行窗口直接使用该命令2、在其它模块中的package.json中引用命令模块，并增加scripts ...

基础环境在进行高效的SHELL实践之前，首先配置一下基础环境，当然首先是需要一台MacOS电脑。这里采用: zsh + oh-my-zsh + zsh-completions + zsh-autosuggestions 。具体安装步骤如下: # 切换默认SHELL为 zsh$: chsh -s /bin/zsh# 安装 oh-my-zsh$: sh -c "$(curl -fsSL https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh)"# 安装 zsh-completions$: git clone https://github.com/zsh-users/zsh-completions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-completions# 安装 zsh-autosuggestions$: git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions安装完成后，轻松敲打几个命令，该提示的、补全的也都如预期般的展示，的确大大的提升了命令输入的效率。 命令别名减少输入的另一个办法就是对拼写复杂的命令设置简易的别名。alias别名命令最常规的用法就是，定义别名。当然这是alias命令的主要功能之一。不过它还具有其它功能，不细看的话很容易被忽略掉。 不妨通过tldr命令查询看看alias的功能列表： $: tldr aliasaliasCreates aliases -- words that are replaced by a command string.Aliases expire with the current shell session, unless they're defined in the shell's configuration file, e.g. `~/.bashrc`.- List all aliases: alias- Create a generic alias: alias word="command"- View the command associated to a given alias: alias word- Remove an aliased command: unalias word- Turn `rm` into an interactive command: alias rm="rm -i"- Create `la` as a shortcut for `ls -a`: alias la="ls -a"不难看出，alias命令还有另外检索的功能，该功能在我们设置别名时先判断是否已经存在别名非常有用。 ...

前言这是一篇关于如何使用 NodeJS 构建高性能、高可读性的现代化命令行工具的博客。每当我们想要创建一个基于 NodeJS 的命令行工具时，就会衍生出一堆问题需要解决，比如如何准备开发环境，如何打包转译代码，如何使代码在转译后保持可调用的状态同时尽可能的压缩体积，以及怎样设计项目分配 Command 与 Option 等等，这会浪费巨大的时间，而且并非一定有成果。这时你可以注意到社区几乎所有的命令行工具都是自成一派，并没有严谨的框架或约定约束，也无所谓的最佳实践，这使想要特别是第一次想要开发命令行工具的开发者望而却步，或是几番努力最后却不尽如人意。 举个例子来说，腾讯的 omi 是一个有众多使用者的框架，但其命令行工具 omi / omi-cli 却让人贻笑大方。仅一些简单的下载和创建模板的任务，造出长篇大论的文件不说，下载时依赖数千，包的体积巨大，整体项目毫无设计几乎是随心所欲、天马行空，这就是开发者本身并不擅长此道，只学会了 糊屎。（何谓 糊屎，参阅 JS 优雅指南 2） FUNC 的出现就是为了解决这些问题。func 本身的实现参阅了社区内诸多基于 NodeJS 的命令行工具的优秀实现，与流行的框架设计思路相结合，以优雅的设计、小体积、高性能 等为目标，同时关注开发者体验，大幅度的提升了命令行工具项目的可扩展性与可读性，几乎是如今 NodeJS 社区中开发命令行工具的最优解。我们可以尝试使用 func 构建一个命令行工具。 构建项目在以前流行的一些命令行参数解析的库中，我们在构建项目前需要准备大量的脚本与配置，甚至还要解决文件权限、bin、代码转译等等问题，但使用 func，我们可以仅通过一行命令初始化项目： npm init func项目初始化后进入文件夹，随机使用 npm install 或 yarn 安装依赖，现在就可以正式开发了。可以注意到，func 的项目模板中为我们准备了 start 与 build 2 个脚本，它们都是由 func-service 驱动的，帮助你一键切换开发与生产模式，我们所要做的就是专注于命令行逻辑本身，实现逻辑就够了。 实现逻辑我们可以随意的创建一个类，当它被加上 Command 注解时这就是一个命令，而被加上 Option 注解时就会转变为一个选项: import { Command } from 'func'@Command({ name: 'test' })export class Test {}在命令行中运行 <YOUR NAME> test 时，Test 类将会被调用。选项也是同理。你可以在 constructor 中开始自己的代码，这和你在任何地方写 NodeJS 没有什么不同，当你觉得差不多的时候，运行 npm build 就可以将它打包，一切就是这么简单。 ...

./kafka-server-stop.sh直接执行，无需加任何参数，当前机器中的所有broker都会被停止。

暂时来讲，这是最后一篇关于 cmdr 的系列介绍文章了。 所有这个系列包括： 另一个go命令行参数处理器 - cmdrcmdr 02 - 复刻一个 wgetcmdr 03 - 用流式接口定义命令行参数处理选项cmdr 04 - 简单微服务cmdr 05 - 扫尾 - Tricks/Walks/Hooks这一次的内容算是杂烩乱炖。 Tricks~~debug已经在前文讲述过了。这里不再凑字数了。 --treecmdr 提供了一个内置的选项：--tree。 虽然这是一个选项，但它和 --version 一样是有着命令一样的效果：如果 cmdr 在命令行参数中检测到了 --tree，那么它会忽略已经处理的和将要处理的子命令、选项，直接执行 --tree 的 Action。 要想达到类似的效果并不困难：定义一个选项，重载其 Action 字段到一个响应函数，并且在该响应函数的结尾返回 cmdr.ErrShouldBeStopException，这样就会在该选项被识别时并执行Action后直接退出应用程序了。 --tree 的功能是打印出全部命令和子命令，以树结构方式呈现出来。 一个样例如下图： 这是我在开发阶段执行 examples/demo 小程序所得到的结果。Walk for all commands--tree 实际上是利用了 cmdr 内建的 WalkAllCommands() 所提供的遍历方式。 对所有命令及其选项进行遍历，实际上有两种方式：一是利用 Painter 以及相应的内部机制，二是通过 WalkAllCommands 明确地遍历。 PainterPainter 是一个接口。它被用在输出帮助屏这个方面。尽管输出帮助屏只是一个小小的功能，但你还是可以自定义它的行为。你可以自行实现 Painter 接口并通过 SetCurrentHelpPainter(painter) 来更改帮助屏的显示内容。 如果你真的想这么做，可以查阅 Painter 的定义，也可以 issue 到我，或许说不定我能够有所建议。 ...

cmdr 04 - simple micro-service based on cmdr v0.2.21My ado is too much. 所以这次直入主题，谢绝吐槽。不知道 cmdr 干嘛用的，无妨看看前文 另一个go命令行参数处理器 - cmdrcmdr 02 - 复刻一个 wgetcmdr 03 - 用流式接口定义命令行参数处理选项那么，golang适合做后端开发，无论是 gRPC 还是 RESTful 都是它的强项。 一旦我们想要开发一个微服务时，抛开核心逻辑不谈，也不论 DevOps 方面究竟是 K8s，还是 Docker，还是裸机，总要面对一个启动、调试、测试的日常问题。 cmdr 除了提供命令行参数的解释能力之外，也额外提供了一个daemon插件，它可以帮助你简化日常开发工作，也令你不必关心 pid 文件、日志、退出信号等等问题，也无需重复编排 daemon 相关的命令行指令。 下面介绍怎么使用 daemon 插件，怎么编写实际的业务逻辑。我们以 demo 为例编写一个简单的示例性微服务，并解释具体的做法。 使用 Daemon 插件启用 Daemon 插件启用 Daemon 插件只需一行代码： // Entry is app main entryfunc Entry() { logrus.SetLevel(logrus.DebugLevel) logrus.SetFormatter(&logrus.TextFormatter{ForceColors: true}) daemon.Enable(svr.NewDaemon(), nil, nil, nil) if err := cmdr.Exec(rootCmd); err != nil { logrus.Errorf("Error: %v", err) }}实现 daemon.Daemon 接口启用 daemon 插件，需要你实现 daemon.Daemon 接口，并编写一定的包装代码来连接 cmdr, daemon 以及你的业务逻辑。 ...

cmdr 03 - 用流式接口定义命令行参数处理选项基于 v0.2.17 转眼已经来到了 cmdr v0.2.17 了，为了解决此前版本中关于子命令和选项定义语句的太多嵌套的问题，我们实现了流式调用接口（Fluent APIs）。 cmdr 是我发布的一个开源的 golang 命令行参数处理器。它是 golang flags 的替代品。之所以发布它，是因为已有的 command line UI 三方包无法满足我的日常要求，迫不得己自己造一个。如果尚未有了解 cmdr 怎么使用的，不妨抽空浏览我的早前文章，以求获得一些基本概念： 另一个go命令行参数处理器 - cmdrcmdr 02 - 复刻一个 wget稍后我会继续针对 cmdr 的用法做介绍文章。 至于本文呢 ，只是简单讲述一下如何使用 cmdr 的流式接口（Fluent API）来完成定义。 定义 RootCommandroot := cmdr.Root("aa", "1.0.1").Header("aa - test for cmdr - no version")rootCmd = root.RootCommand()第二句是拿到一个 *cmdr.Command 指针，稍后可以做一下相关的其它操作。 此外，rootCmd 作为函数返回值，也便于被用到向 cmdr.Exec() 做传递参数。 func buildCmds() *cmdr.Command { root := ... rootCmdr = root.RootCommand() ... return rootCmdr}func main() { if err := cmdr.Exec(buildCmds()); err != nil { logrus.Fatal(err) }}定义命令 Command顶级的命令其实就是 RootCommand 的 子命令，所以： ...

cmdr 02 - Covered for wget 基于 cmdr v0.2.11继 Getting Start 之后，我们来介绍如何用 cmdr 复刻一个 wget 的命令行界面，并具体介绍 Command 和 Flag 的各个细节以及 cmdr 能够做到哪些别人做不到的事。 此外，我们也声明一下，Getting Start ('另一个go命令行参数处理器 - cmdr') 的内容有了一些轻微的变化，因为这两周来，我们已经不停地增加了很多特性来完善 cmdr 的能力，期间有一些不恰当的策略、衍生的命名、采用的算法都有所调整，虽然尽力避免变化，但它是不可免的。我们是期望给你的编程界面越来越完美，让整个编写的流程流畅化，自然化。 wget 的参数wget 本身是一个 GNU 应用程序。它的命令行参数有长有短，短参数可能有两个字符，此外参数被分为若干个分组。请看一部分截取： 这将是我们复刻的基准。 cmdr 都能做到些什么 - First我们曾经做过多个应用，不同的开发语言，不同的目标，有的是练练手，有的是眼前有个事情有点烦、不好处理、一怒之下就干，有的是有特定的目的例如一个RESTful服务，等等。 所以，要想满足那么多的情况下命令行参数的组织和设定都能被很好地表示，不夸张地说，迄今数十年来，我们没有找到一个命令参数解释器能够完成这个任务。把时间限定在最近几年，把开发语言限定在 Golang，C++，Python 等几种之内，依然没有谁真的能这么称呼自己。现有的命令行参数解释器都有这样那样的不如意： 短参数不能重复，哪怕是在多级命令结构下也必须全局唯一；不能分组；分组后顺序随机或者字母序，开发者无法干预，无法按照自己的意愿提供最好的顺序；短参数需要两个字母、或者三个字母的缩略语，更能表达参数原意时，基本上大多数现有的命令行参数解释器都废了；想要长参数显示为“--progress=TYPE”的式样，其中的 TYPE 还可以被复用；想要 git -m 的效果，结果费尽了力，终于实现了一个，然而受制于既有命令行解释器的结构，实现的坑坑洼洼的，自己都难以满意；想要和配置文件挂钩，没错挂钩了，然而需要写很多代码来安排；想要 /etc/program 加载配置文件，结果累了；想要 /etc/nginx/sites.avaliable 那样的效果，自己 watch 了，却合并不了新的配置到已经加载和构建好的配置中，也无法有效地通知应用的业务层按需取用新的配置条目；还有很多遇到这些情况时，多数时候只能忍了，毕竟没有太多精力专门去搞参数问题，还有大把的业务需要去完成的对吧。 cmdr 选择和实现 wget-demo 也是为了展示自己大体上能够解决命令行参数处理的多数问题。不过和其它命令行参数的策略不同地在于：别人通常会对参数值的类型做很多文章，例如支持 string/int/slice/map 的多种式样，或者提供 validator，或者采用 Golang 结构 Tag 方式来挂钩参数类型处理器等等。但是 cmdr 在参数类型方面只能说有且够，整体的重心并不在这些方面。 ...

vue-cli 源码阅读前一阵写了一个平时自己用的 React 模板项目 boone-react，想着以后每次写新项目的时候就可以直接拉取现成的模板就不用自己配置了。但完成后，就发现每次都需要 git clone 下来还是比较麻烦的，而且如果之后有不同的模板需求，不方便扩展，于是自己写了一个 CLI 工具 boone-cli，这样在本地安装执行相关命令就可以完成基本需求了。但感觉还是有很多不足，想着去看看之前用过多次的 vue-cli 是怎么实现的。 Tip：阅读的是 vue-cli 的 v2.9.6 版本。因为 CRA 和 vue-cli@3.0 都是整合了一个插件系统来完成的项目新建工作，重点就不在命令行工具了而是插件系统如何实现了，增加阅读负担，自己菜还找借口从项目结构开始把测试文件、构建配置文件、文档文件去除后，项目的源码结构如下。其中： package.json 不多说，注意里面的 bin 字段，这里定义了安装后执行的命令以及命令所对应的执行脚本bin 目录下是命令文件，在敲入 vue init 等命令后会执行对应的文件lib 目录下是一些自定义函数，会在各个执行脚本中用到分析完结构就知道了，主要需要看的就是 bin 和 lib 两个目录下的文件了。 ├── bin│   ├── vue│   ├── vue-build│   ├── vue-create│   ├── vue-init│   └── vue-list├── lib│   ├── ask.js│   ├── check-version.js│   ├── eval.js│   ├── filter.js│   ├── generate.js│   ├── git-user.js│   ├── local-path.js│   ├── logger.js│   ├── options.js│   └── warnings.js├── package.jsonbin 目录vue 脚本这里使用了 commander，主要用来处理命令行工具的开发。vue 这个脚本文件主要功能就是给用户提示，提示 vue-cli 工具的用法和所有命令。PASS！ ...

cmdr 是另一个命令行参数处理器(Golang)。 Golang 自己带有 flags 进行命令行参数处理，算是便利的，然而和 Google 一贯的做法相同，非常独，非常反人类。 在计算机人机交互界面的历史上，命令行的交互方式只有一种是贯穿始终，得到传承和延续的，那就是 getopt 以及 getopt_long。说起 getopt 来也可以讲述一个怪长的故事，然而本文不做此打算。无论如何，你需要知道的就是，getopt及其交互界面已经是POSIX的一部分，一个卓有成效的程序员、开发者、科学家，或者计算机从业者，对于这个界面都已经是训练有素，无需成本了。你可能在用着它，但你或许只是没有意识到它的存在而已。GNU的大部分命令行小刀都采用了这样的界面，所以，例如tar, gwk, gzip, ls, rm, …，以及无法列举的那些工具都是这样的界面。 所以，自行其是，自己搞一套，并非不可以。但我可以不买账。 那么，这并非我独自一人的自赏。我们只需要知道，在 Golang 的开源圈子里，已经有了数十种 getopt-like 的复刻本，用以为 Golang 开发的应用程序提供更好的命令行界面。这里面不乏 viper/cobra, cli 那样的巨作，也有一些小巧精干的实现。 cmdr 也是这么一个 getopt-like 的实现。和已有的其它实现不同之处在于，cmdr基本上原样复制了 getopt 的表现。也就是说，一个典型的 Unix/Linux 应用程序，例如 cp，mv 等等，是怎么做的，那么基于 cmdr 的应用程序也就是怎么做的。这里讲的当然是关于命令行参数怎么被解释的问题，而非应用程序的具体逻辑。 让我们来看看都有哪些具体方面。 POSIX 约定POSIX 表示可移植操作系统接口（英语：Portable Operating System Interface，缩写为POSIX）是 IEEE（电气和电子工程师协会，Institute of Electrical and Electronics Engineers）为要在各种UNIX操作系统上运行软件，而定义API的一系列互相关联的标准的总称，其正式称呼为IEEE Std 1003，而国际标准名称为ISO/IEC 9945。此标准源于一个大约开始于1985年的项目。POSIX这个名称是由 理查德·斯托曼（RMS）应IEEE的要求而提议的一个易于记忆的名称。它基本上是Portable Operating System Interface（可移植操作系统接口）的缩写，而X则表明其对Unix API的传承。 电气和电子工程师协会（Institute of Electrical and Electronics Engineers，IEEE）最初开发 POSIX 标准，是为了提高 UNIX 环境下应用程序的可移植性。然而，POSIX 并不局限于 UNIX。许多其它的操作系统，例如 DEC OpenVMS 和 Microsoft Windows NT，都支持 POSIX 标准。 ...

很久之前在 Github 上发现了一个用 Golang 来实现的命令行图形界面库，一直想用来做点东西。 https://github.com/rivo/tview周末闲来无事用它写了个基于命令行的 Redis 图形界面客户端，目前已经基本可用，欢迎大家试用，Just for fun ????。 项目地址为：https://github.com/mylxsw/redis-gli。