现代 Linux 工具
其他资源
- 现代 Unix：常见 Unix 命令的现代/更快/更合理的替代方案
- 新（或较新）的命令行工具
- 秘技宝典：各类资料/速查表/实用工具
- 超赞Linux软件：精选Linux应用清单
- archlinux实用工具：附说明的完整清单
CLI替代方案
bat |
带语法高亮和git集成的cat克隆版 |
exa |
ls/tree的现代替代品，已停止维护 |
eza |
基于exa分支的现代ls/tree替代方案 |
lsd |
新一代ls，向后兼容 |
delta |
git与diff输出查看器 |
ncdu |
带ncurses界面的直观du工具 |
dust |
用Rust编写的更直观du版本 |
duf |
更优的df替代方案 |
broot |
支持导航的增强版tree |
fd |
替代 find 的简洁、快速且用户友好的工具 |
ripgrep |
极快替代 grep 的工具，支持 gitignore 规则 |
ag |
类似ack的代码搜索工具，但速度更快 |
fzf |
通用型命令行模糊搜索替代方案 |
bfs |
基于广度优先搜索的替代方案 |
mcfly |
快速浏览 shell 历史记录 |
choose |
人性化且快速的 cut 替代方案，有时可替代 awk |
jq |
JSON 数据的 sed 替代方案 |
sd |
直观的命令行查找替换工具，替代sed |
bottom |
跨平台图形化进程/系统监控工具 |
glances |
top/htop替代方案 |
gtop |
终端系统监控仪表盘 |
hyperfine |
命令行基准测试工具 |
gping |
带图表的 ping 工具 |
procs |
ps 的 Rust 替代方案 |
httpie |
面向API时代的现代化友好型命令行HTTP客户端 |
curlie |
兼具curl的强大功能与httpie的易用性 |
xh |
性能优化的 httpie 替代方案 |
zoxide |
受 z 启发的智能 cd 命令 |
micro |
现代终端文本编辑器 |
nnn |
轻量高效的终端文件管理器 |
新增命令行工具
up |
支持即时实时预览的管道工具 |
辅助工具
ManKier |
用简洁美观的手册页解释shell命令 |
tldr |
附实用示例的精炼man页 |
tealdeer |
tldr 的快速 Rust 实现 |
explainshell |
将命令行参数匹配至其帮助文本 |
cheat.sh |
整合 cheatsheets 与 tldr 页面 |
图形化工具
baobab |
图形化磁盘使用率分析工具 |
stacer |
图形化系统优化/监控工具 |
这些工具或许客观上更优（我未曾测试），但我逐渐意识到（如同许多人一样）：若你需要更换操作系统安装环境、配置虚拟机或进行SSH远程操作，坚持使用这些工具只会陷入永无止境的艰难博弈。我不愿在每个新环境中反复配置这些工具，甚至不愿在个人电脑上使用它们，而在其他地方却使用传统工具。
掌握经典工具，精通它们，你的生活会轻松许多。
有些人绝大多数时间都在自己的机器上工作。便利性带来的收益是值得的。他们对经典工具的掌握已足够应对偶尔在其他服务器上工作的需求。
并非所有人都是整天手动登录大量独立异构服务器的系统管理员。
没错，这基本就是我的日常。举例来说：我日常使用搭载大量插件的neovim，但当进入未安装neovim及我配置/插件的服务器时，运行vim甚至vi也并非难事，多数功能都能正常运作。
其他工具也类似——虽然存在“现代”替代方案，但“经典”版本在多数默认发行版中早已预装可用。
况且通过SSH登录机器的工作流正日渐式微。如今系统环境如此精简，甚至连SSH都不安装了。
或许有人能SSH登录，只是你不行 🙂 虚拟私有服务器终究是虚拟私有服务器，尽管如今流行托管Kubernetes之类的新潮方案。但若你租用实例/服务器，SSH仍是主流登录方式。
这想法虽可爱却脱离现实。
基础设施或许如牲畜般可替换，但通过肛探——呃，SSH调试仍是常态。
某些工具的卓越性能足以抵消安装过程的小小不便。我深谙经典工具之道，但每次都会选择fd和ripgrep。
就我而言，当某天困惑为何“grep”找不到明显存在的文件，却发现是“ripgrep”忽略了gitignore中的文件时——那便是它被我从系统卸载之日。
我从未要求这种行为，更没时间在基础软件上听什么花哨的“现代”观点。
每当看到“现代”二字，我读到的往往是“不成熟”。
我绝不愿用行为反复无常的不成熟工具替换稳定的基础实用程序。
五年前编写的脚本必须原样运行。
但你确实主动要求过。因为ripgrep明确宣传过这个默认行为。文档也明确说明它并非符合 POSIX 标准的 grep。这是刻意为之的设计差异，并非不成熟。或许问题不在于软件本身，而在于你在机器上安装新工具的筛选流程不够严谨。
要知道：你依然可以使用 grep！所以我才另行开发了替代方案。
听起来你的问题在于将
grep别名指向了ripgrep。ripgrep从未打算成为POSIX grep的直接替代品，其主观上更便捷的用法永远无法取代grep的成熟度和普及度。注意：若需禁用 ripgrep 对 .gitignore 的过滤，请将
RIPGREP_CONFIG_PATH指向包含-uu参数的配置文件。来源：
– https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md#c…
– https://github.com/BurntSushi/ripgrep/blob/master/GUIDE.md#a…
看来我确实错了。我确实直接用ripgrep替代了原工具。
这怪我！
这些年来我一直在摸索这个工具，最终在.rgrc里配置如下：
–smart-case –no-messages –hidden –ignore-vcs
并通过以下命令指向配置文件：
.zshenv 3:export RIPGREP_CONFIG_PATH=“$HOME/.rgrc”
虽非完美方案，有时仍需使用经典转义的grep，但多数情况下运行良好。
ripgrep的README首段已明确说明该行为：
https://github.com/BurntSushi/ripgrep
+100
我真心喜欢Nix的一个原因是，我的配置基本能在任何地方运行（只要宿主操作系统是Linux或macOS——不过这两种环境就是我关心的全部）。安装Nix甚至不需要root权限，因为有多种方式可以实现无root安装。
不过确实，万一没有Nix时我也能熟练使用经典工具。这并非二元选择，两者完全可以兼得。
你打算在随机Docker容器里安装Nix吗？
正因如此我才强调仍精通基础Unix工具。若调试频率高到必须安装Nix配置才能高效工作，显然存在根本性问题。
例如在$CURRENT_JOB项目中，我们通过堡垒主机访问数据库（暂不讨论此方案优劣，这是公司既定流程）。90%的情况下，仅凭堡垒主机提供的功能（该主机未安装Nix）就能完成所需操作；若需深入分析，可将文件在堡垒主机与本地电脑间复制传输。
mise是不错的折中方案。
我不确定mise相较于Nix如何成为“理想折中方案”，毕竟获取Nix静态二进制版本非常容易。如今它甚至无需创建
/nix目录即可独立运行——若我没记错，直接执行二进制文件就会在~/.local/state/nix生成所需环境。更何况Nix的功能远比mise强大。> 倘若你更换操作系统安装环境
apt-get/pacman/dnf/brew install <所需全部软件>
更换操作系统时，这些工具（及浏览器、文本编辑器等常用软件）本就需要重新安装。
> 或通过SSH远程连接
SSH连接时虽无图形界面，但这并非回避图形化工具的理由。
> 甚至在个人电脑上混合使用这些工具，在其他地方使用传统工具
我实在看不出问题所在。我使用过其中一些工具，它们确实方便，但并非不可或缺。比如bat命令：它并非cat的替代品，只是带语法高亮的数据输出工具，让工作更轻松，但没有它也无妨。
> apt-get/pacman/dnf/brew install <所需全部软件>
若真能如此简单就好了。并非所有工具都来自同名软件包（delta是git-delta，“z”是zoxide——在新系统安装时，我可不敢保证能立刻想起这些名称）。更棘手的是，你可能不喜欢每个工具的默认配置，因此需要复制或重建配置文件（最好能在使用这些工具的计算机间同步）。
不过我认为Nix确实提供了不错的解决方案。它让你能通过Nixfile清晰地列出所需软件包，同时设置默认值并提供配置文件。虽然仍需维护（我选择将配置文件设置为可编辑状态，这虽不太符合Nix精神，但比起每次微调或测试都要编辑重部署，我宁愿先修改再提交到配置仓库供后续部署），但比起维护某种
apt-get install [包列表]脚本，这种方式显然优越得多。安装后执行 git clone <点文件仓库> 并 stow .
Chezmoi 极大简化了操作：https://www.chezmoi.io/
我只粗略浏览了网站，但它似乎只管理点文件。因此我需要单独维护脚本保持软件包同步。仅含安装命令的脚本不够完善——比如当我决定停用abcxyz时，希望脚本能自动卸载。软件包与点文件的版本差异有时也会引发问题。
用谷歌搜索调整配置，不到一秒甚至不到十秒就能搞定…
强烈赞同。我不明白为何要牺牲99%以上的时间效率，只为在不到1%的时间里——当我登录到无法在本地目录安装软件的SSH目标机时——换取微不足道的体验改善。这甚至算不上权衡取舍——我并非在优化曲线的某个部分，而是直接削平高峰段来维持整体便利性的恒定水平。
> 既然要更换操作系统，这些工具（常用浏览器、文本编辑器等）终究还是得重新安装。
关键在于，有时你需要SSH连接到轻量级无头服务器之类设备，而这些环境根本无法（或难以）安装软件。
正因为“有时”，才不该在其余80%的时间里无谓地束缚自己。
我个人有一个Ansible剧本，用于在任何需要频繁使用的命令行界面中部署常用工具集；（几乎）所有本地安装都避免需要root权限。整个过程只需一分钟——而我就能获得所有便利功能。如果连这分钟都不值得花，那我在这台机器上停留的时间本就不长，根本无所谓。
这属于特殊情况。若需频繁SSH登录轻量级服务器，即便本地已安装其他工具，默认命令集通常也能满足需求。
这些工具的操作逻辑确实高度相似，基本都具备相同的“肌肉记忆”选项。
> 通过SSH连接时没有图形界面，但这并非回避使用图形化工具的理由。
关键差异在于：工具的长期使用必然形成肌肉记忆。
习惯了替代命令行工具？当你在其他机器的SSH会话中登录时，肌肉记忆会狠狠惩罚你——因为你终究会尝试运行那个替代工具。
习惯了GUI工具？这种情境下受影响的概率要小得多。
> 你习惯了替代命令行工具？
是的。
> 那么肌肉记忆会让你吃尽苦头
不会。
我也习惯使用pt-br键盘，母语输入更轻松，但使用美式键盘也无妨。就肌肉记忆而言，键盘适应难度要高得多。
举个非技术例子：去日式餐厅我会用筷子，用起来很顺手。在家里我用刀叉，因为它们让生活更便捷。我不会为了应对日式餐厅而强迫自己每天用筷子。
这违背了UNIX哲学。工具“专注做好一件事”也意味着当更优替代方案出现时，工具就该被替换。这正是简单实用工具的核心价值。我认同应先掌握经典工具——这关乎职业生涯的长期投资，但绝对也该学习新型替代方案。我对bat或eza兴趣不大，但像fd（find替代品）或sd（sed替代品）这类工具确实能大幅节省时间。
> 掌握经典工具，精通它们，你的生活会轻松许多。
赞同，但这并不妨碍你使用/学习替代方案。根据可用工具选择你偏好的选项即可。我明白这种做法可能不适用于编程语言（尽管如此，我们多数人仍掌握多种语言）或图形应用程序，但对于分页器这类工具，切换使用本应轻而易举。
当经典工具需要助力时：
Awk与sed。
我欣赏新工具的理念，但掌握基础构建模块同样重要。《Unix强力工具》曾助我快速入门——这类实用小工具实在太多。
Miller就是我常用的工具之一（我的发行版也自带该工具）
我确实更偏爱某些工具，因其用户体验更佳，但唯一会安装在每台Unix设备上的工具是ripgrep。
本想说我们该永远沿用Unix初始版本。但GNU项目本身不就违背了这个理念吗？
我认为这种观点极其愚蠢：不该让过去决定未来。UNIX属于历史，历史属于史学家，它不应成为塑造当代工程师工作环境的基石。
关键在于我们始终处于连续演进的某个节点，而非某个标准被永久固化的固定时刻。记得2000年代初配置Solaris机器时，那些预装的SysV工具令人痛苦不堪，第一件事就是下载GNU核心工具包。如今这些工具已成为“标准”——当然，除非你用的是Mac。新一代工具正在涌现（终于），那些主张“GNU工具无处不在，坚持使用就好”的人，完全忽视了让这种局面（基本）成为现实所付出的努力。所以没错，我们不该让GNU工具的历史决定当下生存方式。
其实连“Unix”本身也存在差异（BSD开关与SysV开关之别）。理论上POSIX本应消除这些差异，但它们始终存在。如今人们更可能在GNU Linux环境中工作（这只是市场份额事实，非道德评判，BSD爱好者们请注意）。因此对多数人而言，GNU才是基准。
我倾向于使用这些“现代”工具，前提是它们能直接替代现有工具。
例如：我在自定义配置脚本中将 ls 别名设置为 eza。在多数场景下，eza 的功能基本等同于 ls。
若身处完全由我掌控且配置符合偏好的环境，我便会启用默认设置更优雅的 ls 版本。
若置身其他环境，ls命令依然无需多想就能正常运作，肌肉记忆如故，我并未失去任何东西。
若某工具运作方式与标准套件迥异，它必须真正物有所值，我才会考虑使用。
初获Unix账户时[1] 我身处GNU Emacs文化圈，从1989年到2005年左右都使用Emacs。后来我决定转用vi，主要基于三点考量：(1) 减少与主流GUI编辑器的冲突——这些编辑器将^S赋予了与Emacs截然不同的功能；(2) Vim不会插入破坏剪切粘贴的续行符； (3) 经常需要协助修复未安装emacs的故障机器（如包数据库损坏等），能依赖预装编辑器解决紧急情况非常实用。
[1] 就像有次朋友“批量拨号”本地所有号码并把列表贴到BBS上，我发现某些号码竟能用“uucp/uucp”之类命令登录。贝尔公司安保部门明明知道他拨遍了全区电话，却决定让计费部门处理——毕竟他父母订的是计量服务。
我学会了Ansible，只需执行一条命令等待十分钟，就能为新Linux机器配置好所有所需软件
我对vi编辑器相当熟悉，尽管90年代在UNIX系统上工作时主要用XEmacs，但拜访客户时，他们的服务器系统极可能只安装了ed和vi。
如今许多人没意识到自己有多幸运——不必在分时系统上进行UNIX开发，虽然云系统某种程度上复刻了那种体验。
ed才是标准文本编辑器。
高中打字考试用edlin就够折磨人了，ed也好不到哪去——当年客户们对此深有同感。
更别说它在许多发行版里都不默认安装。真倒霉。
> 更别说它在许多发行版里都不默认安装。真倒霉。
ed（发音为独立字母/ˌiːˈdiː/）[1]是Unix及类Unix操作系统的行编辑器。它于1969年8月开发完成，是Unix操作系统最早诞生的组件之一[2]。至今仍是基于Unix的操作系统中POSIX和开放组标准的组成部分
因此这是这些发行版的缺陷。
我刚入职新公司，花了一天时间在云端开发机上配置工具和点文件。这台机器将伴随我整个职场生涯，值得投入精力。我主要通过Nix包管理器安装工具，省去了编译和适配特定Linux发行版的麻烦。
掌握Ansible等工具后，就能实现跨操作系统（OSX/Linux/甚至Windows）的复杂环境部署。我搭建环境时代理系统尚未如今日完善，但如今操作应相当轻松。
个人认为，花些时间优化配置以利未来顺畅迁移至新机器是值得的。
我深有同感。年轻时曾耗费大量时间用oh my zshell等工具“优化”命令行界面。
结果登录到busybox环境时却手足无措。
幸好我学会了使用vi、grep、sed…
我唯一调整的环境配置是键盘布局。年轻时学了Colemak布局，至今每天仍在享受它带来的便利。
此处并非针对特定工具的评论，但我习惯将常用非标准工具存放在~/bin/目录，迁移系统时随身携带。文中提及的工具也可采用相同方式管理，能让适应过程更轻松些。
我拥有部分这类工具，但它们并非“客观上更优”。许多工具通过色彩、条形图等元素美化界面——在配置完善的终端中效果不错，但在管道处理中则不然。部分工具本质上是全功能的终端图形界面（TUI），属于运行在终端中的图形化工具，而非传统命令行工具。
有些工具虽智能，但有时我需要“笨拙”模式：例如ripgrep会遵循gitignore规则，而我常不需要这种行为。不过此工具提供关闭选项（-uuu）。这类工具普遍存在这种设计逻辑：默认智能模式，需手动启用选项才能切换为笨拙模式。
因此这些工具并非“客观上更优”，它们通常更先进，但未必符合实际需求。它们是对经典工具的补充，绝非替代品。
我绝不会直接在发行版系统上配置工具和开发环境。所有配置都部署在可通过 proot/toolbx/bwrap 访问的根文件系统中。这不仅避免在不同电脑重复配置，更因发行版升级屡次摧毁“花哨”工具的惨痛经历，使手动配置变得得不偿失。
https://proot-me.github.io/
哇，这太酷了。比起其他沙盒工具，这个看起来亲和力强多了。
同意，不过有些工具确实够好用，我会确保在能安装的地方都装上。'ag'是我常用的快速grep工具，所有高频使用的设备我都会安装它。
对某些人而言，“逆流而上”的过程本身就是乐趣所在
配置工具链有多难？
我有套Chef食谱，能自动为虚拟机部署所有常用工具。初始化虚拟机时，它会自动安装鱼壳（fish shell）等非标准组件。该Chef食谱还统一管理我的SSH密钥和配置。
我确实不愿被定制工具束缚，但回避优秀工具也非良策。总体而言，采用更优质的工具才是正道。
构建优质环境的途径往往多种多样：
我主要依靠Ansible脚本安装配置常用工具。
还有个未被提及的实用技巧：通过sshfs将目标系统挂载到本地。这能让你在另一台机器上高效使用本地工具和配置！
同理，Dvorak键盘布局效率更高，但我坚持使用QWERTY——毕竟它几乎通吃所有场景（像AZERTY这类小变体还流行吗？我们法国办公室用的就是“国际版”布局，跨国协作时主要痛点是“@”键位置错乱和反斜杠失效——后者可通过用户名@域名的形式登录Windows系统，替代原有的域用户名格式）
我使用Dvorak布局已有24年。99%时间都在用自己的设备，完全没问题。剩余1%情况下，我也能用QWERTY布局进行双指盲打。
至少在ripgrep中我坚持使用它。
这些年来Fzf帮我节省了大量时间，实在太棒了。
确实如此。我也经常使用它，还有依赖它的Neovim插件fzf-lua。
“我不愿成为环境的产物，而要让环境成为我的产物。”
说得太对了。
作为需要登录数百台不同网络、不同客户服务器的用户，自定义工具几乎毫无价值——它们在90%的系统上都无法使用。
我仅在系统中安装极少数附加工具，这些工具已纳入默认Ansible配置，能快速部署到系统中，但我始终坚持精简原则。
我管理的系统95%是Debian或Ubuntu，因此基础配置基本相同，仅需添加ack、etckeeper、vim、pv、dstat等工具。
“服务器”是关键概念。该页面列出的部分工具只是常见系统管理工具的“改良版”，确实未必值得安装。但有些工具本质上是开发工具，通常只安装在少数用于编程的机器上，这类工具或许值得考虑。
最吸引我的是：
在我前任岗位中，rg和jq已被纳入标准AMI及基础容器镜像。虽然这增加了CVE漏洞暴露风险，但无疑是值得的。
试试https://github.com/TomWright/dasel
是否有工具或SSH扩展能将这些应用程序引入远程会话？
这种方案可行吗？理论上可将这些小工具存入临时文件夹使用，甚至实现自动化。
是否存在安全隐患？这些工具是否需要超出远程会话权限的访问权限？
核心问题或许在于应用程序的可移植性？
这确实是普遍诉求（我也有同感），那么是否存在解决方案？
这些“作为某人…”的帖子有何意义？没人关心这些工具是否符合你精心筛选的远程安装工具清单。你完全可以在本地电脑安装它们以获取便利。
这正是“豆汤理论”（“万一我不爱吃豆子呢”）的现实体现。
我认为这源于主角症候群，或者说就是老派的经典自恋
Emacs作为操作系统（虽非完整系统，但你懂的）之所以能让人快速适应各类系统环境，正是基于此原理。故有名言：“GNU才是我的操作系统，Linux不过是当前内核”。
作为一位资深的Linux管理员，我完全赞同你的观点。正因如此，当有人告诉我正在学习Linux时，我首先建议他们直接在终端输入“info”命令并通读全部内容——这足以让他们领先于90%的管理员。但我并未说明原因： 因为掌握系统内置工具的模块化脚本能力，并善用完善的文档资源，本质上就是践行Linux哲学。
当然，我们都记得当年系统只配vi编辑器、连nano都不默认安装的岁月。但如今我们做的是幂等性CI/CD配置，添加自选的TUI编辑器本该是小菜一碟。
> 我们还记得系统只配有vi编辑器，连nano都不是默认配置的年代
你在说什么？我至今仍在现代AWS环境里用最新EC2机器过着那种日子！
你又把这个网站当成个人邮箱了。这是公共留言板，所有内容都不是专门为你写的——包括这篇博文。
真希望表格能加个“解决什么问题”的列。哦对了，“用Rust编写的”这种理由不算数。
“用Rust编写的”
笑死。确实如此。我曾在某大公司任职时，开发团队介绍产品时被问及与竞品差异，对方回答“我们的用Go语言写的”。#扶额
Rust重写项目确实令人疲倦，如今已成梗，但其中确实存在优秀工具。
以我亲身经历为例：我曾以为oxipng只是更快的optipng。最近深入研究才发现它远不止于此。
详见：[https://op111.net/posts/2025/09/png-compression-oxipng-optip…] (https://op111.net/posts/2025/09/png-compression-oxipng-optipng-fileoptimizer-cwebp/)
若新工具具备实际性能或功能优势，那么它就是“解决什么问题”的答案——无论采用何种编程语言。
说得对。
> 但那里也有真正优秀的工具。
问题就在于此。它们究竟有多优秀？谁能评判？基础UNIX工具并非像这些“Rust工具”那样“一日成型”。
若竞争对手用Python/Ruby/Bash等语言编写，这确实是差异化优势。但面向普通用户营销时，你必须强调“它快速可靠且易于分发”——毕竟他们不会知道这些特性源自Go语言。
但任何语言都能写出低效、难以维护的脆弱垃圾代码。所以即便对手确实用Bash之类编写，你仍需说明自身实现的真正优势——若是性能优势，请提供实证数据证明你在真实场景中测得的效果，而非仅凭“我们用$语言编写所以必然高效”的臆断。
> 任何语言都能写出低效、难以维护且脆弱的垃圾代码。
确实。跑车也能开得很慢。但若规划长途旅行方案，你会选择跑车还是自行车？
另外我至今还没见过用Go或Rust写的又慢又难维护的脆弱垃圾代码。虽然理论上可能存在，但概率要低得多。
> 另外我至今还没见过用Go或Rust写的又慢又难维护的脆弱垃圾代码。虽然理论上可能存在，但概率要低得多。
需要引用来源。/s
不。关键在于这种实现方式能带来什么优势（比如性能、可靠性等）。当你说“我们的用Go写的”时，客户不会立刻掏出支票簿。
这正是你回复的帖子所表达的观点
我仍在回应开篇那句话。即便对精通Go或Rust等语言的优秀工程师而言，这也不是差异化因素。每当工程师将编程语言作为首要卖点时，我便知道这不过是他们的个人偏好。你可以写出优秀的Python、Ruby、Go或Rust代码，也可以写出糟糕的Python、Ruby、Go或Rust代码。诚然某些语言更适合特定场景（比如用Ruby写内核程序显然不妥），但编程语言本身绝非核心竞争力——真正决定成败的是你用它创造了什么。
> 你可以写出优秀的Python、Ruby、Go或Rust代码，也可以写出糟糕的Python、Ruby、Go或Rust代码。…编程语言本身绝非决定性因素
这被称为“灰色谬误”，非常常见。
https://www.lesswrong.com/posts/dLJv2CoRCgeC2mPgj/the-fallac…
许多条目确实包含这些细节——例如“带语法高亮”、“ncurses界面”和“更直观”。我同意“用Rust编写”、“现代化”和“更优越”这类描述确实没什么用！
不过有些比较对象本身就不对。例如：
> cat clone 带语法高亮和Git集成
这种对比毫无意义，因为cat本就不是用于查看文件的工具。你应该将自己的工具与more/less/most系列工具对比，其中部分工具已具备语法高亮甚至更复杂的转换功能。
没错，我在另一条评论里也提过同样的观点。不过出于好奇，这些分页器究竟如何实现语法高亮？我试过它们都没原生支持这个功能。
通过vim管道处理？/s
使用非GPL许可证也不算数。
这些工具很多在Windows上也能用，这正是我喜欢它们的原因。
我向来喜欢这类清单。多数人应该都能成功采用其中一两款工具。对我而言是ripgrep和jq——前者是grep的绝佳替代品，后者则解决了我的特定需求。我也会尝试列表里的其他工具，lsd和dust都让我很感兴趣。
看着大家不断完善我们的工具库总是令人欣喜。即使新工具对我没有直接用处，我也欣赏开发者付出的心血。这些工具本身就很出色，往往通过添加现代元素让优秀工具更臻完善。
感谢所有付出心血的开发者，你们正让这个社区变得更美好。
我们许多Linux管理员都有类似清单。我的清单特别注重将技术栈尽可能GPL化。不过ikrima.dev这份清单的格式确实很棒！其他内容也很精彩，值得细细品味。
我几乎终日泡在终端里。但这些工具无一例外：解决的问题我根本用不上；系统里压根没安装；却莫名拥有数万颗GitHub星标。
我真心搞不懂这是什么情况。
> 我基本都泡在终端里。但这些工具无一例外：解决的问题我根本用不上；系统里压根没装；却莫名其妙收获了数万颗GitHub星星。
> 我真心搞不懂这是什么情况。
我几乎整天泡在音乐库里。但每个流行歌手的歌我都听不惯，我的歌库里根本没有他们的作品，可他们的专辑销量却莫名其妙地达到数百万张。
我真心搞不懂这是什么情况。
开玩笑归开玩笑，你试过用这些工具吗？以前我也搞不懂为什么有人用vim，直到我自己真正尝试过。
> 开玩笑归开玩笑，你试过用这些工具吗
没有。
> 我以前也不懂为什么有人用vim，直到我真正尝试过。
问题就在这儿。我建议你试试安装Emacs。
你居然不用fzf？那在终端里过得可真够苦啊。直接运行它没那么实用，但几乎所有shell都有fzf插件支持，让你能用Ctrl+R模糊搜索bash_history（或fish_history等），Ctrl+T则可模糊搜索当前目录文件。
fish在Ctrl+R和Tab键下就能模糊匹配，无需fzf。
出于好奇，如何递归搜索文件时忽略隐藏文件（如
.git），同时仅匹配特定扩展名？（例如rg -g ‘*.foo’ bar）我同样频繁使用命令行，这是最常用的操作之一，但尚未找到用Unix内置工具实现的优雅方案。
（同样的问题也适用于查找匹配正则表达式或通配符的文件[忽略明显不需要的内容]，例如
fd ‘._foo.*’。）_这取决于目录规模。若文件数量有限，我会先用
find枚举所有文件，再通过grep过滤结果，最后借助xargs执行实际的grep bar操作：（这段命令我能凭肌肉记忆完成。）
若遍历隐藏文件/目录的开销较大，我会直接让
find排除它们。这样还能用find自带的-exec功能替代xargs：（这个命令我查了资料才弄明白。）
谢谢，这确实很好地说明了我为何更偏好
rg和fd的简洁界面。如果只是偶尔使用（或在脚本中），这些示例其实完全没问题。但我在工作时每天要多次从命令行搜索文件，因此更倾向于更流畅的操作界面。顺便提一句，我认为
git grep可能是解决我提出问题的最佳内置方案，但坦白说我不记得如何用它同时实现两个必备功能：仅搜索匹配通配符的文件，以及将搜索范围限定在当前目录而非仓库根目录。此外我还需要掌握其他版本控制系统的同类命令（我常用的还有另一种VCS）。>如果只是偶尔操作（或写在脚本里），那些示例确实可行。但我在工作时每天要多次从命令行搜索文件，因此更倾向于更简洁的界面。
有道理。若需频繁操作，我会将`find`命令封装成函数/别名添加到.bashrc中，并将其与其他配置文件一同存入家目录的版本控制。这样迁移新环境时，只需将该仓库克隆到新家目录，大部分自定义设置就能即刻生效。
确实有时我也这么做，尽管可能过于偏好个人习惯。关于这种做法有几点说明：
1. 不建议使用shell函数或别名（如
bashrc）实现，因为这些脚本无法在其他上下文中调用，例如Vim和Emacs对shell命令的内置支持。解决方法很简单：创建可在任意位置调用的脚本（我个人收集的这类脚本在此https://github.com/robenkleene/Dotfiles/tree/master/scripts）。个人仅将 Bash 函数用于涉及运行时状态的场景（如扩展 PATH 路径这类常见操作）。2. 更关键的是，我不希望始终局限于搜索
*.foo模式，而是需要灵活且设计完善的 API，支持动态调整搜索范围。#2 尤其关键，这涉及工具哲学层面的思考。我曾犯过的错误是将当前工作流固化为脚本等定制方案。这种做法不可取，因为当任务需求变化时（而任务复杂度理应随时间增长），这些脚本便失去实用性。换言之，切勿基于当下工作流选择工具，否则就是在给自己设限。应选用强大工具，它们能支持你处理任何任务，且具备近乎无限的扩展性。“书架的价值不在于已读之书，而在于待读之书。”
在此说明为何我在此处https://news.ycombinator.com/item?id=45569313建议不要采用此方案（坦白说我确实认为这是个绝佳方案）
此方法的缺陷在于仍会遍历所有隐藏文件夹，这可能造成资源消耗（例如在拥有庞大修订历史的
.git/目录的Git仓库中）。-not -path ...仅阻止实体输出，不会阻止遍历。要真正阻止遍历，需使用-prune选项。grep -ri foo ./*
隐藏文件中的匹配结果对我而言并非痛点
那么这是否解答了“我完全不明白这里发生了什么”的问题？不搜索隐藏文件（或第三方依赖项——
rg通过忽略解析也会自动实现）不仅是锦上添花，对软件工程师在代码库中执行多项任务而言更是必需？这并不适用于楼主所问的特定场景。
这是POSIX规范的实现方式。你可能需要将其封装为函数存入.bashrc文件
在此补充说明：我已在https://news.ycombinator.com/item?id=45569313中阐述过不采用此方法的原因
核心Unix工具集如此强大，仅凭它们就能轻松应对日常需求。许多替代工具虽更出色，但并非必需，且默认环境下绝非普遍可用。
整天在终端里干些什么，竟毫无提升工具集的冲动？难道你所有工具都是自己编写的？
没有jq工具，你如何筛选和转换大型JSON文件？
我们中很多人日常工作中根本不用JSON，我知道这很奇怪，但事实如此。
我在工作中唯一用JQ的地方就是解析Copilot API响应，好记住模型名称——仅此而已！说实话，我完全可以跳过它直接读json文件。
这份清单里居然有jq。说实话我巴不得永远用不上它解决的问题，但现实就是如此。
ripgrep我装过，但只通过文本编辑器集成使用。fzf很适合搭建临时TUI界面。fd或许有价值（据说比find快），但我对find已经足够熟悉。
文章里提到的“新一代ls”工具家族实在令人费解。
据我观察，这类工具似乎更受“用Rust/Go重写”派的青睐。换句话说，你已经不再属于酷炫圈子了。
我见过用Go写的在线电台播放器，在Atom n270上运行时因采用浮点运算的糟糕ANSI音频可视化效果而慢得离谱。而用Cava或其他可视化工具配合mpd+mpc，用200倍少的资源就能实现相同效果。
我真希望有个由统一团队开发的现代化工具套件，能提供设计一致的参数、配色、表格等功能。
本想阅读这份清单，但配色方案堪称我见过最难辨识的：深灰底色上叠加暗蓝灰文字，再配以蓝灰色的高亮效果。天啊。
若这里有新手设计师，请务必记下这个反面教材。
这可是2023年的文章。和多数“现代工具”一样，其中半数恐怕早已被更新潮、更炫酷的替代品取代了。
这里列出的工具很多，即便减半仍有相当价值。
我认为恰恰相反。这些工具大多只是在重新发明轮子——那些基础GNU工具其实非常强大，只要花时间掌握就能发挥巨大威力。
人们似乎根本不明白为何需要这些“现代”工具。这叫“合理的默认设置”和“改进的用户体验”。
那些“基础GNU工具”确实糟糕透顶——虽然人们熟悉它们且无处不在，但它们就是纯粹的垃圾。
许多常用操作本该用grep/find等工具轻松完成，却要输入大量随机乱码才能实现。这些乱码又难以脱口而出，因此至少得定义成堆的别名。
或者你可以直接使用那些开箱即用、具备基本“合理默认值”和基本合理用户体验的工具。
这真的不复杂。和“Rust”毫无关系。
有些人就是喜欢用这样的咒语折磨自己：
听起来是技能问题。
第二个项目是
ls/tree的现代替代方案，已停止维护
“停止维护”在我看来可不怎么“现代”啊…
这就是林迪效应：ls这类老工具之所以长存，正因它们早已历久弥坚；而现代工具往往存续时间不足以成为经典。
https://en.wikipedia.org/wiki/Lindy_effect
下一行直接列出了它的替代品eza。
如同优秀的开源项目，它如今由社区分叉维护，而非仅靠单一维护者支撑
eza: https://github.com/eza-community/eza
README顶部居然有广告。
哎呀，不行。
这可是个高度聚焦AI的云端终端模拟器。他们居然还有胆量称其为“面向开发者”。
工具本身没有广告。README放广告有什么问题？
问题出在所有地方。
大家总在讨论如何报酬开源开发者，可当有人真正付诸行动尝试盈利时，又被说得一无是处。
做也错，不做也错。
要不你赞助项目让他们撤掉广告？
恰恰相反，这才是“现代”的真实写照。真好奇这些工具何时会无人维护。Coreutils虽问题重重，但其维护历史比许多列举工具的作者出生还要久远。
补充说明：许多工具开发者在GitHub开放赞助通道。我几乎每天使用bat/fd，很乐意支持https://github.com/sponsors/sharkdp#sponsors
虽未尝试delta，但diff工具我首推diftastic：
https://difftastic.wilfred.me.uk/
相较纯字符级差异比较，它实现了巨大飞跃。
我在Mac上工作，发现某些默认工具显得有些过时：GNU核心工具包及其相关组件往往停留在2000年代中期的版本。与其替换或对抗系统工具，我选择通过几个额外工具进行补充。坦白说，这些工具大多只是对macOS自带功能的边缘性升级，唯独fzf堪称生产力飞跃。无论是模糊搜索命令行历史记录，还是交互式自动补全功能，都让日常操作体验焕然一新。
>部分默认工具略显陈旧：GNU核心工具包及其相关组件常停留在2000年代中期的版本
这是因为它们并非GNU核心工具集，而是BSD核心工具集——其设计初衷就是极简主义。（顺带一提，我认为这正是Linux/GNU能压制BSD的原因之一：尽管后者的系统架构更优越，但前者的默认用户体验显然丰富得多。）
许多工具在Windows上也能用。
我的Windows 11系统就安装了hyperfine、fd和eza，可能还有其他现在记不起来的工具。
通过winget安装也极其简单。
每当这类清单出现时总会引发热议，但我认为至少有两款工具能真正提升终端体验：
`fd`：首先我认为其参数语义远胜于`find`，不过这更像是锦上添花而非核心优势。但它在多数环境下比`find`快得多，这点确实值得称道。而对我而言真正的杀手锏是`-x`参数。该参数允许对单个搜索结果执行其他命令——虽然
find也能通过xargs等工具实现类似功能，但fd提供了极佳的占位符语法[0]，省去了使用basename等工具解析文件名并生成新文件的繁琐步骤，且支持并行执行。例如批量转换图片时，只需一行快速可读的命令：fd -e jpg -x cjxl {} {.}.jxl`rg`（又名`ripgrep`）：坦白说它纯粹是速度机器。在目录搜索中远超`grep`的性能，开辟了诸多新可能。比如在我的前端项目（约3444个文件）中搜索
isLoading，rg能瞬间完成（0.10秒内），而grep则需要数分钟。但
ripgrep还有个让我特别欣赏的特性，我认为任何“现代”的命令行工具都该具备：它能将输出格式化为JSON。倒不是我特别推崇JSON，但至少这是种定义明确的交换格式。传统“CLI工具仅输出”人类可读“格式，若想使其”机器可读"，往往需要反复调试awk和sed。这使得管道传输和脚本编写变得繁琐且易出错。而能输出JSON格式，通过jq处理后直接传递给下一工具，这种体验堪称终端操作链中缺失的环节。命令行界面最大的优势在于其天生具备组合性和可脚本化特性。但它缺乏通用数据交换格式，这正是脚本编写时最耗费精力的环节。即便存在诸多争议，JSON格式的出现确实将所有环节紧密衔接。
值得特别提及的还有
zellij——相较于tmux，它提供了更合理的用户体验；以及helix文本编辑器，它本质上是neo-vim的变体，但拥有更优的用户体验（尤其适合新手），内置更多实用功能，同时保持比nvim更快的运行速度（IMEX输入法），且在功能匹配度上与nvim的插件生态相当。编辑补充：还想推荐 difftastic（https://github.com/Wilfred/difftastic），这是款支持语法高亮的差异比较工具。虽然我用得不多，但它确实能让某些差异对比变得清晰易读。
[0] https://github.com/sharkdp/fd?tab=readme-ov-file#placeholder…
当朋友推荐 fd 和 ripgrep 时，我曾短暂质疑它们的实用性。
但实际使用后，性能差异简直天壤之别——如今任何新系统我都会第一时间安装它们。
> 比如在我的前端项目（约3444个文件）中搜索
isLoading：> – rg 瞬间完成（<0.10秒）
> – grep 耗时数分钟
grep会尝试搜索.git目录。若项目是JavaScript，它可能搜索node_modules；若Python则搜索.venv。ripgrep会忽略隐藏文件、.gitignore和.ignore文件。你可以尝试使用
git grep替代，ripgrep仍会更快，但差距不会那么明显。虽然这可能是搜索时间巨大差异的合理解释，但至少还有两种其他可能。
首先是并行处理能力。执行
grep -r时，多数grep工具（如GNU grep、BSD grep及macOS自带版本）不会启用并行处理，而ripgrep会。这足以解释搜索时间感知上的显著差异。其次是grep的实现。虽然GNU grep本身通常被认为相当快（尤其在POSIX区域设置下），但许多其他grep实现却并非如此。事实上，它们可能极其缓慢。例如，比较 macOS 上的 FreeBSD grep 与 ripgrep（我截取了
time命令输出，仅保留wc -l部分以缩小输出规模）：这只是直接比较，完全排除了并行处理和过滤等因素。纯粹是算法层面的差异。而两者差距竟达_数量级_之别。
上述任何一种解释，单独来看都足以造成性能感知上的巨大差异。仅凭“ripgrep远快于其他工具”这类简短描述，根本无法判断究竟是哪种因素（甚至可能是全部三种）导致了这种差异。
上述命令版本信息：
不，我特意确保在没有.git、node_modules等文件的目录下运行。它就是这么慢
> 但对我来说杀手级功能是
-x参数。它允许对单个搜索结果调用其他命令，这点find配合xargs等工具也能实现。但fd提供了极佳的占位符语法[0]，省去了用basename等工具解析文件名并生成新名的麻烦，且支持并行执行。例如批量转换图片时，只需一行快速可读的命令：fd -e jpg -x cjxl {} {.}.jxl该功能继承自
find的-exec选项，甚至沿用了相同的占位符{}（虽然不确定是否支持{.}）。find仅支持{}，不支持{/}、{//}、{.}等形式，因此常需通过解析技巧实现基础功能，如获取“完整路径去除扩展名”或“仅文件名去除扩展名”等操作。我认为 GNU parallel 也有类似占位符，但我更倾向直接使用
fd。确实如此，而且说实话，
fd本质上就是find+parallel的组合，但我更欣赏它作为单一工具的简洁性，这样就不需要额外安装 GNU parallel 了 🙂像 dasel 这样的优秀工具对输入和输出格式都无所不包。
最好能标注该工具是否默认包含在发行版中，或需要安装哪个包——毕竟工具的实用性取决于其可用性…
务必试试批量重命名命令行工具 f2。它堪称精雕细琢的魔法利器：https://github.com/ayoisaiah/f2
几周前还被 Hacker News 推荐过。
btop是值得关注却常被忽略的竞品。
它外观虽花哨，但我更欣赏其实用性，尤其是用于浏览进程列表的树形视图。我不太喜欢这类工具的全彩模式，因此特别欣赏它能轻松切换至灰度模式的设计（甚至可通过TUI设置菜单实现）。
qq理应上榜。它类似jq但支持多种文件格式（包括JSON、YAML、XML等），并拥有超酷的交互式TUI模式。
https://github.com/JFryy/qq
这看起来很有价值，我会深入研究。
我本想补充说明：Unix/Linux命令行工具诞生于数据基本按行处理的时代（例如每行一条数据库记录）。后来XML和更近期的JSON格式出现后，grep和sed这类工具就无法处理这些格式了。不过你抢先一步了，算是吧。
你试过https://github.com/TomWright/dasel吗？
duf在监控磁盘空间方面相当出色，界面色彩和图表都挺不错。但它不太适合作为其他工具的输入源。
btop用于观察系统运行状况总体情况一直很可靠，最新版本优化了CPU进程列表的懒加载机制。
zoxide 适合在系统中反复访问相同位置。它能记住目录路径，省去输入完整路径的麻烦。
baobab 不是快三十岁了吗？
tldr 是个超棒的工具，95%的情况下我都能快速找到所需信息，省去翻阅手册页的麻烦。
现代不一定意味着更好。mpv 作为 mplayer 的替代品虽更优秀，但在某些场景下 mplayer 反而更快（比如老旧机器）。
确实，sff和soap都需要配置config.h文件，但在老旧机器上它们的运行速度远超任何Rust工具。
> bat 这是个无用的cat替代品。cat本用于文件拼接，ANSI色彩会破坏其功能。
作为cat替代品确实没用，我同意。文章不该这么称呼它，尽管程序的GitHub页面确实自称“cat克隆版”。它更像是语法高亮工具结合git diff查看器（我确实有意见：这该是两个独立程序，而非合一）。
我使用'cat'有两种场景：
将文件内容管道传输至某个进程。
显示某些短文件的内容。
如今（1）用重定向（< 或 >）实现更优。我仅在测试管道时使用cat——当只需几行输入时，我会用'head'之类的工具。待管道运行正常后，直接将命令行中的'head'替换为'cat'，比重新排列整个单词更省事。
而(2)的情况也很少是正确解决方案——我常发现文件比预想的更长，最终不得不使用'more'（实际用'less'）。
因此，能实现颜色标记的'cat'替代工具在我看来几乎毫无用处。
没错，别把它当作cat的替代品，而应视为着色工具。若你永远不需要着色功能，那也无妨，直接忽略bat！但我发现它在阅读源代码或Markdown时相当实用。
> bat只是个无用的cat。cat用于连接文件，而ANSI颜色会破坏连接。
摘自README：
>当bat检测到非交互式终端（即管道输出至其他进程或文件时），它将作为cat的直接替代品，退而输出纯文本内容
bat既能满足常规cat功能，又能解决那些“猫没用”的场景——它既是普通猫，也是进阶猫。
>bat就是个无用猫
除了在终端阅读源代码外，我无法将bat视为“无用猫”或cat替代品。它更像是带语法高亮的less，或是只读版的vim。
赞同此观点。cat擅长“输出内容”，bat则擅长以更易理解的语义方式在终端呈现信息——这是两种不同的使用场景。
已有ccze工具能实现语法高亮，无需刻意替代cat(1)。
是否有独立的命令行语法高亮工具？若尚未存在，我们似乎需要开发一个。它应能接收输入流、语言参数，并支持可选的语法高亮配置。这种工具可附加于任何命令，使最终输出具备对应的语法高亮效果。
问题部分在于“命名/营销策略”。Bat将自身定位为cat的替代品，而非more/less的替代品。我认为这混淆了核心概念。
我认为这是因为使用cat快速查看文件极为普遍。它具备利用终端滚动缓冲区而非跳转到分页程序的优势。在此场景下它确实是cat的替代方案。
不过我向来不在意用cat查看文件时缺少语法高亮功能。因此该工具对我而言并无实际用途，若需查看带语法高亮的文件，我仍会继续使用vim/neovim。
或许该命名为“lest”？意指用Rust实现的less/most替代方案。不过这确实偏离了more/less/most的命名主题。
> mpv才是mplayer的更佳替代品
见仁见智。