共 3 篇相关文章
这篇讲的是 Mac 终端用户常遇到的一个“洁癖”小问题：执行 `clear` 命令后，屏幕看似干净，但向上滚动依然能看到历史输出，而且在搜索时，之前的内容其实也还在。 文章直接点明了 `clear` 命令的这两个局限性，并给出了一个更彻底的解决方案——使用 iTerm2 自带的快捷键 `Command + K`。这个操作能真正清空屏幕缓冲区，让历史记录在滚动和搜索时都彻底消失。 如果你经常在终端里工作，希望获得一个完全空白、不受旧内容干扰的工作界面，这个小技巧能立刻提升你的使用体验。
在 Windows 上用 SecureCRT 或 XShell 连接 Linux 服务器时，通过 sz、rz 命令传输文件已是常规操作，但在 Mac 上使用 iTerm2 默认只能依赖 scp。这篇文章提供了让 iTerm2 支持 sz/rz 协议的具体配置方法。 文章首先强调服务器端需安装 lrzsz 工具（例如 CentOS 上使用 `yum install lrzsz`）。在 Mac 端，核心步骤是通过 brew 安装 lrzsz，并下载两个用于处理 ZMODEM 协议的脚本（`iterm2-send-zmodem.sh` 和 `iterm2-recv-zmodem.sh`）。随后，需要在 iTerm2 的 Profile 设置中添加两个触发器：一个匹配 “rz waiting to receive” 时调用发送脚本，另一个匹配特定接收标志时调用接收脚本。配置完成后，iTerm2 就能像 Windows 下的终端那样，通过 sz/rz 方便地进行交互式文件传输了。 整篇文章的思路很清晰，从实际使用场景的差异入手，逐步分解服务器端与客户端的配置要点，最终实现了在 Mac 上复用这套高效的传输方式。
这篇文章从一个常见的终端报错切入，探讨了在 iTerm2 中使用 grep 处理大文件时，频繁遇到的 "Broken pipe" 错误。作者首先描述了问题场景：当执行类似 `grep "xxx" filename | head` 的命令，且输出内容很多时，终端会刷出大量错误信息。 其根本原因被归结为管道通信机制与终端缓冲特性共同作用的结果。具体来说，当管道的下游命令（如 head）提前获取到所需行数并退出时，管道被关闭，但上游的 grep 可能仍在向已断裂的管道写入数据，从而触发错误信号。而在 iTerm2 这类现代终端中，其独特的 I/O 缓冲处理可能进一步加剧了这类信号的可见性，导致错误被频繁输出。 针对这一问题，文章提供了实用的解决方案。一个核心思路是使用 `grep` 的 `--line-buffered` 选项，确保输出立即刷新，减少缓冲区积压。另一个方法则是用 `tr` 命令来替代直接的管道连接，以改变输出缓冲的行为。这些方法能有效抑制 Broken pipe 错误的产生。 总的来说，这篇文章清晰地剖析了一个在命令行高阶使用中容易遇到，但常被误解的棘手问题。它不仅解释了“为什么会发生”，更给出了“如何解决”的具体命令，为日常使用 grep 和管道的开发者提供了一份清晰的避坑指南。
