Tools

写在前面 这类文章在互联网上其实已经泛滥了，我本来也不打算写。但一方面某些工具确实改变了我的工作方式，值得记录一下；另一方面我有不少朋友问过我类似的问题，与其每次重复解释，不如写成文章。 先说清楚一点：工具这种东西有非常浓厚的个人色彩，没有好坏优劣之分，只是每个人看重的东西不一样。「差生文具多」这句话本质上是一种自嘲，不是用来攻击别人的武器；同理，用某个工具也不应该成为你炫耀的资本。把工具本身当成某种身份符号，反而本末倒置了——有点像崇拜那个你在哪里读书而不是你读了什么书一样。求同存异，工具服务于人就好。 我的选型理念 大概有这么几条原则，按重要程度排列： 开源优先：不是为了装，是为了在厂商「喂屎」的时候有得选。《自由软件，自由社会》我虽然没完整读过，但那个道理我是认同的。商业公司不是慈善机构，功能阉割、涨价、后门——当你的迁移成本高到一定程度，你就只能吃屎。 跨平台：我同时在用 macOS 和 Linux，偶尔还要连一些 Linux 服务器，一个只能在一个平台用的工具对我来说打折扣。Windows 现在用得少了，但也不是完全不接触，选工具时的标准是至少「能用」就行，不需要体验完美。Windows 上 CLI 生态和 UNIX 系确实不在一个量级，如果真要在 Windows 上做点什么，基本上也是开个 WSL 解决，而不是指望 cmd/PowerShell 那边。 不被 vendor locked：和开源有关联，但不完全一样。核心配置最好是纯文本的，这样我可以用 git 管理，随时迁移，不依赖任何厂商的同步服务。 不 all-in-one：一个工具做好一件事（UNIX 哲学），然后组合使用。把所有东西塞进一个超级 App 听起来很方便，实际上某一部分拉垮了你整个工作流都得跟着受苦，还有隐私风险集中的问题。 极简+实用主义，CLI 和 GUI 并用：能用 CLI 解决的问题不一定非要 GUI，但有好的 GUI 我也不排斥，不存在「用 GUI 就是不够 hardcore」这种奇怪观念。 当然，有些领域受制于现实情况，或多或少会违背上面的原则。特定场景特定分析，后面会提到。 操作系统 / 设备 主力设备 工作：公司发的 Mac（具体型号懒得说，反正不是自己买的，用着就行） 个人：自己买的 Mac mini + 一台装了 ArchLinux 的老笔记本（Magicbook 2019）+ 一台 2019 款 MacBook Pro（发热降频严重，但内存相对大，勉强还能用，主要用来跑一些对算力有一定要求的本地任务） 手机：Android 日常 + 老 iPhone 备用，基本只用来打电话、刷视频、MFA验证之类的 小型 VPS：自建一些服务用 为什么用 Linux 之前专门写过一篇：笔记本折腾Linux碎碎念。简短版本：Windows 在这台老机器上已经烂到不可接受，而且微软近年来的所作所为（Recall、强制更新、莫名其妙的后台服务……）让我实在没有继续用的理由。装 ArchLinux 之后内存占用从 70%+ 直接降到 400MB，老机器焕然一生。 ...

前言 本文是什么 终端工具FZF的简单介绍和入门 「个人」对此工具的使用和实践，尤其是一些扩展使用方式 【矫情】由小及大，怎么联想到一些其他的东西的 本文不是什么 不是“最佳实践” 「最佳实践」是指在特定领域内经过实践检验并证明具有卓越效果的技术、方法、流程、活动或机制。它们之所以被称为「最佳」，是因为这些实践能够在提高效率、降低成本、提升质量、确保安全、增强客户满意度等方面展现出超越平均水平或现有做法的优势。 这篇文章显然配不上这个称谓 不是系统性的使用教程，更不是使用手册 RTFM 😊 Wiki FZF是什么 基于终端和命令行的工具（CLI） 提供「模糊」搜索的功能（Fuzzy Search） 提供一个简单但直观的TUI （Integrated with Other Tools） 基础用法 查找文件：直接使用 你可以直接在命令行下面输入对应的命令，-m表示多选，默认行为是列出当前文件夹下的所有文件，选中后按回车会把路径/文件名显示在命令行上 fzf fzf -m vim $(fzf -m) 还可以通过环境变量配置预览效果、窗口大小、快捷键等。 因为是环境变量，所以如果在Shell配置文件里将其export，让它被子进程继承，那么所有的相关配置无需重复配置，便可以在子进程（例如Vim中）生效，后面将在Vim集成章节中稍稍展示一下。 典型例子如下（具体含义请参见官方文档）： FZF_DEFAULT_COMMAND FZF_DEFAULT_OPTS FZF_DEFAULT_OPTS_FILE 简单语法 fzf支持一套语法（丐版正则），让你能在fuzzy的过程中，还是有一定的搜索效率，以下仅列出部分，更多请参考官方文档 Token Match type Description sbtrkt fuzzy-match Items that match sbtrkt 'wild exact-match (quoted) Items that include wild ^music prefix-exact-match Items that start with music .mp3$ suffix-exact-match Items that end with .mp3 !fire inverse-exact-match Items that do not include fire !^music inverse-prefix-exact-match Items that do not start with music !.mp3$ inverse-suffix-exact-match Items that do not end with .mp3 与Shell集成 查看Shell命令历史 使用快捷键Ctrl+R查看Shell命令历史，如果你使用的是原始的bash或者zsh的话，基本可以替换原来的功能，使用起来友好得多；如果你和我一样，主要使用fish，那可能不一定用得上，但我由于个人使用习惯，目前仍然在使用fzf的这个功能，而不是fish自带的那个也蛮好用的历史记录。 ...

Introduction Many people would say that configuring Vim/Emacs(or some other obsession with tools) is time-consuming and even be “a waste of time” 1. The core point is that tools are paths to the goal, not the goal itself. Quoted2: Obsession with tools is an insidious form of procrastination. This form of resistance masquerades itself as the opposite, as a form of improvement and development. It really reveal one of the reasons why some people are obsessed with tools. I quite agree with it (thus I am not an Emacs guy :) ). ...

I’ve been using zsh as my main shell for years. It works really well, and I love it. But recently, I started to give fish a try, and I found it is great and have set it as my default shell on my Mac. I’m gonna give you my reasons, for your reference. Its autosuggestion and completion functionalities work out of the box, which I would have to download oh-my-zsh for zsh. It’s nice but annoying to sync between devices. In fish, you don’t need any other plugins and settings, they just work. Actually that’s the main reason for me, then I can sync my configurations with my dotfiles. It is really friendly for configuration. I’m not a great hacker and not the kind of guy who wants to dive in everything. Fish offer a web-based config interface. You can invoke it by typing fish_config in the shell, then you can configure your shell by clicking the UI, AND the changes you make are essentially text in several files, which you can carry them with whatever your sync system is. Zsh is strong and nice, but some of its syntax and concepts(some inherited from the older sh/bash) are really hard to understand. For example, “variable substitution” or the “$@/$?/…” stuff. I don’t think they are human-readable. Fish shell language, however, is more like a modern programming language, with better documentation(type help in fish, you will also get a web-based doc!) But I’m not saying that I will use fish ONLY and FOREVER. Zsh is also great and better for some scenarios, so here are my opinions about what kind of people may want to use zsh, even bash. ...

防杠声明Disclaimer 工具不是最重要的，最重要的永远是你的idea、核心逻辑和实现（不局限于编程），除非你的工作就是打磨工具本身 但顺手的工具至少可以让你在实现自己的想法时，不会被无关的事项掣肘，甚至形成瓶颈而半途而废 GUI也很好，但TUI/CLI也有自己的魅力和优势，本文只是强调后者，并不否定前者 为什么使用纯文本+命令行工具 纯文本方便做版本管理，而且很容易按自己的需求进行批量进行格式化/添加删除内容等，不受专有格式的限制（比如markdown/latex vs word，大家如果是用word写自己的学位论文或者什么其他复杂文档的话是不是会存在V1.0、V2.0、V3.0等诸多相似的副本…） 命令行工具，资源占用一般少（主要指前端资源, 现在的跨端应用很多是electron写的，资源占用比较大），且类UNIX系统一般自带，一般也是跨平台的，易脚本化 命令行工具（尤其是通用命令行工具），一般遵循UNIX的“Do one thing and do it well”的设计哲学（见《UNIX编程艺术》），单个工具易于使用（某种程度上可能比一些产品设计不佳的GUI工具认知成本低得多），多个工具之间也容易相互配合（例如著名的使用“管道”连接stdin/stdout） 所以对于我个人，只要不是使用专属工具才能解决的需求场景，在工具的选择上，会比较倾向于可以纯文本配置的命令行工具，另外： 本文也是仅介绍，不介绍深入使用，按需了解，希望起到抛砖引玉的作用。另外像ls/cp/rm/git/…之类的暂时就不提了 虽然工具这个东西比较个人化，但我做这个分享的初衷是，哪怕有一点点帮助到看到本文的读者也值得了 工具介绍 zsh/fish zsh大约是bash的超集，但是有更强的能力（补全/高亮等），mac默认带，配合oh-my-zsh等全家桶体验较好 fish是一个可能更用户友好的shell工具，例如一些oh-my-zsh才有的功能fish都是自带的，且脚本语言更贴近日常使用的编程语言 tldr tldr是一个由社区维护的帮助文档，相比软件自带的help，它旨在提供更“简易”的类cheatsheet式帮助 z / autojump z是用shell编写的“智能跳转”脚本，可以实现自适应的跳转文件夹 autojump是其用更正统的编程语言写的，功能更强的类似软件，但个人的使用场景和z差不多，但是各大包管理器有，所以安装可能更直白，按需使用即可 curl 不多说，超强大的请求发送工具，其实不局限于HTTP/HTTPS，一般我在简易场景下更喜欢用这个而不是Postman之类的图形界面，不是因为curl做不到，而是我懒得查用法了，有ChatGPT或许容易一些🤣 curl is a tool for transferring data from or to a server. It supports these protocols: DICT, FILE, FTP, FTPS, GOPHER, GOPHERS, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, MQTT, POP3, POP3S, RTMP, RTMPS, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET or TFTP. The command is designed to work without user interaction. ...