pry-remote 实现原理揭秘DRb、Pry Hooks 与 stdout 捕获的底层魔法【免费下载链接】pry-remoteConnect to Pry remotely项目地址: https://gitcode.com/gh_mirrors/pr/pry-remote当 Ruby 进程连续运行数天、想查看内部变量状态却又不方便重启时pry-remote就是为这种场景而生的它是一个面向 Ruby 调试器 Pry 的远程调试工具通过DRb让你从本地终端连接到正在运行的程序开启交互式调试会话。本文从底层拆解它的三大核心机制——DRb、Pry Hooks 与 stdout 捕获把这套底层魔法讲透。 整个项目的核心逻辑就集中在一个文件里pry-remote.rb380 行依赖声明见 pry-remote.gemspec。痛点pry-remote 解决了什么问题 传统的binding.pry有一个大限制你必须身处程序运行的那台机器的终端前。对于后台服务、容器进程或远程服务器往往根本做不到。pry-remote 的思路是把这件事反过来服务端在程序关键行写下binding.remote_pry程序暂停并等待连接客户端在自己本机执行pry-remote命令就像坐在程序面前一样调试——看变量、查局部变量、甚至编辑源码。class Foo def initialize(x, y) binding.remote_pry # 程序在此暂停等待远程连接 end end默认监听地址是127.0.0.1:9876可通过环境变量PRY_REMOTE_DEFAULT_HOST/PRY_REMOTE_DEFAULT_PORT覆盖见 lib/pry-remote.rb#L8-L9。整体架构一个客户端、一个服务端用 DRb 打通 pry-remote 本质上是构建在DRbDistributed Ruby之上的一个 RPC 应用组件职责关键代码Server运行在目标进程中启动 DRb 服务收到客户端后拉起 Pry 会话Server#initializeClient一个 Struct保存 input、output、stdout、stderr、editor、thread 六个槽位ClientCLI本地命令行建立 DRb 连接并把原料喂给服务端CLI#connect当remote_pry被调用时服务端做了一件事DRb.start_service uri, client——把Client对象暴露在 9876 端口上。而本机执行pry-remote命令后客户端依次做三件事在随机端口上启动一个自己的 DRb 服务druby://本机IP:0用DRbObject拿到服务端Client的远程代理把六样原料塞进服务端输入、输出、stdout、stderr、编辑器和当前线程。关键点在于这六样原料不是简单的数据而是活的管道——这正是下面三处魔法的伏笔。魔法一IOUndumpedProxy输入为什么能来自本机 DRb 反直觉的地方在于远程调用默认传输的是对象的序列化描述dump在另一端重建。如果直接把本地$stdin传过去服务端只会重建出一个空壳IO 对象读不到你敲的任何按键。pry-remote 用IOUndumpedProxy解决见 lib/pry-remote.rb#L39-L93诀窍只有一行class IOUndumpedProxy include DRb::DRbUndumped # 告诉 DRb别序列化我只传引用包含DRb::DRbUndumped后代理对象被按引用而非按值传递——readline等所有方法调用都发生在客户端本机。于是服务端 Pry 索要一行输入时真正读取的是你本机的键盘。服务端还配套了一个InputProxy见 lib/pry-remote.rb#L15-L33它探测原始输入对象readline方法的 arity自动决定是否传提示符——因为Pry 靠 arity 判断要不要把 prompt 交给输入对象这个小细节正是能用与提示符不显示的分界线。魔法二Pry Hooks在每次求值前后埋点 Pry 提供了钩子机制允许在求值执行的特定阶段插入自定义逻辑。pry-remote 在 Server#setup 里注册了两个钩子:before_eval→capture_output每次执行输入前先接管输出:after_eval→uncapture_output执行完毕恢复原状。这两个钩子像三明治一样夹住每一行远程执行的代码。setup还顺带做了三项调参关掉分页器pager分页器只在本地终端有意义服务端上它毫无用处于是保存原值后置为false替换system为自定义实现改用Open3.popen3运行 shell 命令并用IO.select把子进程输出泵回输出流见 System——远程会话里! ls -l能用的秘密就在这替换editor为远程编辑器调试中想改源码时文件先在客户端读出、用本地编辑器修改、再写回服务端见 editor_proc。会话结束时Server#teardown 恢复这三项配置、通知客户端线程可以退出并调用DRb.stop_service收尾。魔法三stdout 捕获输出为什么能回到你的屏幕 输入来自本地输出自然要送回本地——否则远程会话就是哑巴。原理其实很朴素Ruby 的$stdout/$stderr只是普通对象随时可以替换。capture_output见 lib/pry-remote.rb#L201-L219做的正是求值前保存旧的$stdout/$stderr换成客户端送来的两个 IO 代理求值后还原回原值。效果是执行期间服务端代码写出的任何输出puts、库的输出、日志都会真实地流到你本机的终端。而客户端的--capture选项默认开启控制是否真的把这两路流交给服务端见 CLI#connect。⚠️ 注意捕获是按求值进行的而非整个会话期间常驻。这个设计更安全——服务进程的其他日志不会被劫持。完整链路从binding.remote_pry到断点恢复 binding.remote_pry也提供别名pry_remote在对象上被调用创建Server并启动见 Object#remote_pry服务端启动 DRb 服务打印Waiting for client on drb://localhost:9876本机pry-remote命令建立连接把六样原料喂给服务端服务端检测到客户端执行setup注册钩子、调整配置Pry.start拉起会话远程调试开始每一行输入钩子捕获 → 代码执行 → 输出回到你的终端 → 钩子还原输入exit客户端通知服务端线程teardown恢复现场服务进程继续运行。最后一点正是 pry-remote 与普通 Pry 的本质区别调试完程序还活着——服务无需停摆就能被打断检查、再无缝续跑。快速上手让 pry-remote 跑起来的最快步骤 安装gem install pry-remote依赖 pry ~ 0.9、slop ~ 3.0见 pry-remote.gemspec在目标程序关键行写binding.remote_pry本机执行pry-remote连接主机与端口需与服务端一致。常用命令行选项一览定义于 CLI#initialize选项作用-s, --server服务端地址默认 127.0.0.1-p, --port端口默认 9876-w, --wait等待服务端启动未起来会自动重试-r, --persist断线后持续重连适合长时间值守-c, --capture捕获服务端 stdout/stderr默认开启-f不加载 .pryrc 与插件、跳过历史 跨机器调试时服务端用-s指定可达 IP客户端保持对应即可客户端比服务端启动晚加上-w会自动重连直到成功。写在最后这套底层魔法值得借鉴pry-remote 没有炫技它把RPC 按引用传参、框架钩子、全局变量替换三种最朴素的机制组合出了完整的远程调试体验。380 行代码值得反复研读学 Ruby 远程通信看DRb与DRbUndumped的用法学框架扩展点看:before_eval/:after_eval钩子的埋点方式学 IO 重定向看capture_output的替换-还原模式。它不只是一个工具更是一份紧凑的 Ruby 胶水工程范本。【免费下载链接】pry-remoteConnect to Pry remotely项目地址: https://gitcode.com/gh_mirrors/pr/pry-remote创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
pry-remote 实现原理揭秘DRb、Pry Hooks 与 stdout 捕获的底层魔法【免费下载链接】pry-remoteConnect to Pry remotely项目地址: https://gitcode.com/gh_mirrors/pr/pry-remote当 Ruby 进程连续运行数天、想查看内部变量状态却又不方便重启时pry-remote就是为这种场景而生的它是一个面向 Ruby 调试器 Pry 的远程调试工具通过DRb让你从本地终端连接到正在运行的程序开启交互式调试会话。本文从底层拆解它的三大核心机制——DRb、Pry Hooks 与 stdout 捕获把这套底层魔法讲透。 整个项目的核心逻辑就集中在一个文件里pry-remote.rb380 行依赖声明见 pry-remote.gemspec。痛点pry-remote 解决了什么问题 传统的binding.pry有一个大限制你必须身处程序运行的那台机器的终端前。对于后台服务、容器进程或远程服务器往往根本做不到。pry-remote 的思路是把这件事反过来服务端在程序关键行写下binding.remote_pry程序暂停并等待连接客户端在自己本机执行pry-remote命令就像坐在程序面前一样调试——看变量、查局部变量、甚至编辑源码。class Foo def initialize(x, y) binding.remote_pry # 程序在此暂停等待远程连接 end end默认监听地址是127.0.0.1:9876可通过环境变量PRY_REMOTE_DEFAULT_HOST/PRY_REMOTE_DEFAULT_PORT覆盖见 lib/pry-remote.rb#L8-L9。整体架构一个客户端、一个服务端用 DRb 打通 pry-remote 本质上是构建在DRbDistributed Ruby之上的一个 RPC 应用组件职责关键代码Server运行在目标进程中启动 DRb 服务收到客户端后拉起 Pry 会话Server#initializeClient一个 Struct保存 input、output、stdout、stderr、editor、thread 六个槽位ClientCLI本地命令行建立 DRb 连接并把原料喂给服务端CLI#connect当remote_pry被调用时服务端做了一件事DRb.start_service uri, client——把Client对象暴露在 9876 端口上。而本机执行pry-remote命令后客户端依次做三件事在随机端口上启动一个自己的 DRb 服务druby://本机IP:0用DRbObject拿到服务端Client的远程代理把六样原料塞进服务端输入、输出、stdout、stderr、编辑器和当前线程。关键点在于这六样原料不是简单的数据而是活的管道——这正是下面三处魔法的伏笔。魔法一IOUndumpedProxy输入为什么能来自本机 DRb 反直觉的地方在于远程调用默认传输的是对象的序列化描述dump在另一端重建。如果直接把本地$stdin传过去服务端只会重建出一个空壳IO 对象读不到你敲的任何按键。pry-remote 用IOUndumpedProxy解决见 lib/pry-remote.rb#L39-L93诀窍只有一行class IOUndumpedProxy include DRb::DRbUndumped # 告诉 DRb别序列化我只传引用包含DRb::DRbUndumped后代理对象被按引用而非按值传递——readline等所有方法调用都发生在客户端本机。于是服务端 Pry 索要一行输入时真正读取的是你本机的键盘。服务端还配套了一个InputProxy见 lib/pry-remote.rb#L15-L33它探测原始输入对象readline方法的 arity自动决定是否传提示符——因为Pry 靠 arity 判断要不要把 prompt 交给输入对象这个小细节正是能用与提示符不显示的分界线。魔法二Pry Hooks在每次求值前后埋点 Pry 提供了钩子机制允许在求值执行的特定阶段插入自定义逻辑。pry-remote 在 Server#setup 里注册了两个钩子:before_eval→capture_output每次执行输入前先接管输出:after_eval→uncapture_output执行完毕恢复原状。这两个钩子像三明治一样夹住每一行远程执行的代码。setup还顺带做了三项调参关掉分页器pager分页器只在本地终端有意义服务端上它毫无用处于是保存原值后置为false替换system为自定义实现改用Open3.popen3运行 shell 命令并用IO.select把子进程输出泵回输出流见 System——远程会话里! ls -l能用的秘密就在这替换editor为远程编辑器调试中想改源码时文件先在客户端读出、用本地编辑器修改、再写回服务端见 editor_proc。会话结束时Server#teardown 恢复这三项配置、通知客户端线程可以退出并调用DRb.stop_service收尾。魔法三stdout 捕获输出为什么能回到你的屏幕 输入来自本地输出自然要送回本地——否则远程会话就是哑巴。原理其实很朴素Ruby 的$stdout/$stderr只是普通对象随时可以替换。capture_output见 lib/pry-remote.rb#L201-L219做的正是求值前保存旧的$stdout/$stderr换成客户端送来的两个 IO 代理求值后还原回原值。效果是执行期间服务端代码写出的任何输出puts、库的输出、日志都会真实地流到你本机的终端。而客户端的--capture选项默认开启控制是否真的把这两路流交给服务端见 CLI#connect。⚠️ 注意捕获是按求值进行的而非整个会话期间常驻。这个设计更安全——服务进程的其他日志不会被劫持。完整链路从binding.remote_pry到断点恢复 binding.remote_pry也提供别名pry_remote在对象上被调用创建Server并启动见 Object#remote_pry服务端启动 DRb 服务打印Waiting for client on drb://localhost:9876本机pry-remote命令建立连接把六样原料喂给服务端服务端检测到客户端执行setup注册钩子、调整配置Pry.start拉起会话远程调试开始每一行输入钩子捕获 → 代码执行 → 输出回到你的终端 → 钩子还原输入exit客户端通知服务端线程teardown恢复现场服务进程继续运行。最后一点正是 pry-remote 与普通 Pry 的本质区别调试完程序还活着——服务无需停摆就能被打断检查、再无缝续跑。快速上手让 pry-remote 跑起来的最快步骤 安装gem install pry-remote依赖 pry ~ 0.9、slop ~ 3.0见 pry-remote.gemspec在目标程序关键行写binding.remote_pry本机执行pry-remote连接主机与端口需与服务端一致。常用命令行选项一览定义于 CLI#initialize选项作用-s, --server服务端地址默认 127.0.0.1-p, --port端口默认 9876-w, --wait等待服务端启动未起来会自动重试-r, --persist断线后持续重连适合长时间值守-c, --capture捕获服务端 stdout/stderr默认开启-f不加载 .pryrc 与插件、跳过历史 跨机器调试时服务端用-s指定可达 IP客户端保持对应即可客户端比服务端启动晚加上-w会自动重连直到成功。写在最后这套底层魔法值得借鉴pry-remote 没有炫技它把RPC 按引用传参、框架钩子、全局变量替换三种最朴素的机制组合出了完整的远程调试体验。380 行代码值得反复研读学 Ruby 远程通信看DRb与DRbUndumped的用法学框架扩展点看:before_eval/:after_eval钩子的埋点方式学 IO 重定向看capture_output的替换-还原模式。它不只是一个工具更是一份紧凑的 Ruby 胶水工程范本。【免费下载链接】pry-remoteConnect to Pry remotely项目地址: https://gitcode.com/gh_mirrors/pr/pry-remote创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
