寻找命令管理方案

背景

我一直接受不了yazi那样的TUI文件管理器，但是windows自带的文件管理还是有很多缺点。  

缺点暂且不提，文件资源管理器页面中是无法直接执行命令的。  

不过地址栏可以输入一些exe的名称，可以直接唤醒，尤其是shell。  

现在的场景是，我不想舍弃文件管理器中当前路径/工作目录这个上下文。  

右键终端可以解决这个问题，但还是不够，还是多了一步。  

• 存在一些低频次场景，都需要工作目录的上下文，但是如果每个都添加一个右键菜单未免太过冗余。 

• 如果不创建，那么

  1. 右键 => 终端
  2. 输入脚本名称执行（可能还记不得叫啥了） 

以往的做法是写个文档，里面标注每个脚本的用法。  

虽然有些杞人忧天，但是体验上还是有些割裂。  

尝试

之前的尝试是，写一个TUI程序，然后用ContextMenuManager为其创建一个右键菜单，获取上下文（当前路径），程序执行直接就开始选择使用什么命令。  

由于是右键菜单打开的，考虑到效率（右手不离开鼠标），使用鼠标左右键参与操作。  

开发过程中注意到vscode拦截了右键，右键是粘贴操作（左键正常）。  

本来想要换Z键来确定（右手不离开鼠标，左边区域用z确定esc退出，这是rpg的键位），然而win11打开新的程序，会自动把输入法切换到中文，于是作罢。  

问题

• 由于我们的是一个独立的程序，所以没办法做到先关闭自身再执行脚本。  

  因此，调用脚本是打开一个新的shell程序。（此处是pwsh）。  

  这里的主要问题是，和平常执行pwsh不同的是，它没有使用windows terminal容器，而是直接使用自己作为外壳。如果在这里面打命令，它是斜体的（而wt里面是自定义的字体）

  

• 还有很多脚本是需要参数的。退一万步说，就算我现在所有的脚本不带参数，不代表我之后写的脚本不需要参数。所以这个复用的美梦就这么泡汤了。  

  在那之前，其实这个TUI程序还需要一个文本输入框，用于检索脚本名称以及其介绍。（因为麻烦所以搁置了）

TUI的缺陷

TUI的缺陷和网页程序有共通之处，比如PWA。  

假如TUI程序是在其他终端中启动的，那么他会受到终端掣肘，最明显的现象就是快捷键被拦截。  

鼠标右键（粘贴）、中键、Ctrl+C、Ctrl+Z等。  

界面开发难度大

虽然下面这个应该是TUI库的问题，但是能看出其难搞之处。  

比写flutter都要痛苦许多，人家封装的有问题你也不会改啊主要是。  

TUI框架

• rust：ratatui

• c#: **Terminal.Gui  **https://github.com/gui-cs/Terminal.Gui

• go: Bubble Tea

• python:  Textual  https://textual.textualize.io/

  风格相当现代化

• js: Ink、Inquirer等，前端脚手架一般都是那种问答方式，和理想中的TUI不太一样。理想中应该是全屏的，或者是有输入框、有鼠标事件的。

yazi

评价

js和python是不能编译成可执行程序的，虽然有打包工具，但是效果总归没那么好。  

C#在开发效率和性能方面取得了最好的平衡，但是如我上面截的图那样，界面的问题还是蛮多的（不过鼠标事件没啥问题）。  

go语言的包管理有些许抽象，不过跨平台搞得很好，我在我的windows设备上直接编译了linux arm64的二进制可执行程序，然后在手机终端上成功运行（Rust就不太行，需要借助别的机器帮忙打包）。Bubble Tea这个框架做得蛮好看，但是对鼠标事件不是很上心。  

rust的那个框架也是蛮现代的。但是代码太难写，AI写的跑不动然后又不会改直接死局。你要学得起劲，真做起东西来巴不得一行代码都不用写。  

回到正题

既然脚本依然是复杂的，那么我想借助一个工具来管理命令。  

最理想的情况其实是剪切板，但是市面上的剪切板没一个靠谱的。  

目前还是用CopyQ，可以分标签也能搜索。  

• 为我的脚本专门加一个标签
• 为我的每个脚本写好相关的介绍，添加到标签中
• 导出标签，分发到互联网上
• 用户只需导入就可以使用？

虽然此处有很大的漏洞，比如需要强制用户使用CopyQ这个软件，本来就很不现实。  

暂且放着不管，先考虑可行性。CopyQ导出标签是私有格式，因此上面的说法行不通。

万策尽！！！

最终还是原地踏步。  

其他

uTools有个插件叫快命令

他的配置文件是json格式，理论上我们可以通过脚本数据处理，将我们的脚本信息添加到里面，从而实现批量添加。  

但是uTools的收费行为还是让我很不爽，它限制了免费用户的插件应用数量。这导致假设我想要开发一个uTools插件就必须和其他插件去抢这10个插件的位置。它的收费基本上是不合理的，因为免费用户只是占用了下载插件的一部分带宽，甚至连云服务都没有，几乎无成本。插件也是人家作者免费开发的……

uTools替代品

目前情况下无可替代。  

• 在尝试的项目有rubick，没有社区，作者估计太忙了，基本不管issue。插件生态稀烂，因为他是中心化的插件管理，使用一个仓库来管理所有的插件，如果有开发者想要提交插件，需要给作者提PR。然而这个作者几乎不管PR。  

• 另一个尝试的是如快,今天刚找到的。过了一年了也没啥起色，插件API都没完善起来，更别说让人去贡献插件了。该软件是闭源的。优势是使用了Tauri，比Electron先进一些。  

万策尽！！！

问题梳理

需要一种合理的易用的命令管理方案。  

最理想的状况是右键调用后选完就能用。  

可能的方法梳理

• 使用uTools的快命令插件，编写脚本批量添加命令项目。这是最省力的方案。  

  需要注意更新逻辑，不能是纯添加。  

• 开发一个类似于快命令的独立程序。这是最自由的方案。比如可以按照标签来导入导出，只需要为我的命脚本单独建一个标签，在更新时就可以直接覆盖，而不是考虑什么合并之类的。  

  这个应用的适用面有些窄，而且看上去就感觉很麻烦。

• 直接分发CopyQ的备份文件，此为下策。  

• 还是和最开始的方案一样，编写文档，然后让用户查文档检索功能。但是这样就多了很多步，属于偷大懒。  

乱点就乱点吧，写到这里我已经写得恶心了。后面再改吧。  

从结果上来说，杞人忧天得有点过分了。首先根本没人用我的脚本，因此其实考虑自己的使用和备份同步问题就行了。但是这样不具备合理性。