Kitty终端模拟器中中断信号处理异常问题分析

在Kitty终端模拟器0.33.1版本中，用户报告了一个关于中断信号处理的异常行为。当使用--hold参数启动包含less命令的会话时，如果尝试通过Ctrl+C中断less的跟随模式(+F选项)，会导致整个窗口意外关闭，而非预期的仅退出跟随模式。

问题现象

典型复现场景如下：

1. 通过Kitty的--session参数加载预定义布局
2. 其中包含使用--hold参数启动的less +F命令（日志文件跟随模式）
3. 在跟随模式下按Ctrl+C试图退出跟随时
4. 整个窗口会被意外终止

相比之下，如果：

• 不使用+F参数启动less
• 或先正常退出less再重新启动 中断信号就能按预期工作，仅退出跟随模式而不影响窗口。

技术分析

通过进程树观察发现关键差异：

• 异常情况下，less的父进程是kitten run-shell实例
• 正常工作时，父进程变为bash shell

这表明问题根源在于kitten run-shell对中断信号的处理方式：

1. 当less处于跟随模式时，Ctrl+C信号会穿透到父进程
2. run-shell没有正确处理该信号，导致进程树被终止
3. 而常规shell（如bash）能够正确捕获和处理中断信号

解决方案

该问题已在最新代码提交中被修复。核心改进点是：

• 增强了kitten run-shell的中断信号处理能力
• 确保信号不会意外终止父进程
• 保持与常规shell一致的中断行为

最佳实践建议

对于终端高级用户，建议：

1. 更新到包含修复的Kitty版本
2. 对于关键日志监控场景，可考虑：
   • 先启动普通less会话
   • 再手动进入跟随模式(F键)
   • 这样中断信号处理更可靠
3. 在脚本中使用trap命令显式处理信号

这个问题展示了终端模拟器中信号传播机制的复杂性，特别是在多层进程嵌套的情况下。正确的信号处理对保持终端会话的稳定性至关重要。