使用 websocketd 把 Haskell 脚本变成 WebSocket 服务：Count 与 Greeter 实战指南
【免费下载链接】websocketdTurn any program that uses STDIN/STDOUT into a WebSocket server. Like inetd, but for WebSockets.项目地址: https://gitcode.com/gh_mirrors/we/websocketd
websocketd 是一款"把任何读写 STDIN/STDOUT 的程序变成 WebSocket 服务器"的命令行工具，Haskell 是它官方支持的语言之一。本文以仓库 examples/haskell 中的两个示例为核心：count.hs（单向推送计数）与greeter.hs（逐行请求/应答的双向交互），完整讲解其源码、启动命令与关键参数（--port、--devconsole、--passenv），并结合 libwebsocketd 的源码揭示底层"STDIN/STDOUT ↔ WebSocket"桥接原理。读完本文，你将能独立把一个 Haskell 脚本改造成可被浏览器直接访问的 WebSocket 端点，并理解--passenv PATH这类参数为何必不可少。
准备工作：环境与两个示例文件
本文假设你已完成两件事：
- 安装 websocketd：在仓库根目录运行
make build或按 README.md 指引构建/下载对应平台的可执行文件，并确保websocketd命令在PATH中。 - 安装 Haskell 解释器 runhaskell：
count.hs与greeter.hs的第一行都是#!/usr/bin/env runhaskell，即通过系统 PATH 查找runhaskell（GHC 自带的脚本解释器）来执行脚本，无需预编译。典型安装位置是/usr/local/bin而非/usr/bin，这正是后续--passenv PATH存在的原因。
两个示例文件均位于 examples/haskell 目录，脚本本身是标准 Haskell 代码，不依赖任何 WebSocket 或网络库——这正是 websocketd 设计的核心价值：用你最熟悉的语言写纯 STDIN/STDOUT 程序，网络层交给 websocketd。
示例一：Count——单向推送流（源码逐行解析）
count.hs 的完整源码如下：
#!/usr/bin/env runhaskell import Control.Monad (forM_) import Control.Concurrent (threadDelay) import System.IO (hFlush, stdout) -- | Count from 1 to 10 with a sleep main :: IO () main = forM_ [1 :: Int .. 10] $ \count -> do print count hFlush stdout threadDelay 500000逐行解读：
forM_ [1 :: Int .. 10]：对 1 到 10 依次执行动作；:: Int显式限定类型，避免歧义。print count：把数字打印到STDOUT（含换行符）。websocketd 以\n为消息边界，每打印一行即触发一条 WebSocket 消息。hFlush stdout：关键一步。Haskell 的stdout默认是块缓冲（block-buffered），管道输出时尤其如此；如果不主动刷新，输出会积压在缓冲区里直到进程退出，浏览器端将长时间收不到任何消息。threadDelay 500000：休眠 500 毫秒（单位微秒），让 10 条消息以每 0.5 秒一条的节奏推送出去。
程序跑完后自行退出，websocketd 会随之关闭对应 WebSocket 连接——所以这个示例天然演示了"进程生命周期即连接生命周期"的语义。
启动命令
原文档给出的启动命令为：
$ websocketd --port=8080 --devconsole --passenv PATH ./count.hs三个参数的作用分别是：
| 参数 | 作用 |
|---|---|
--port=8080 | 指定 HTTP/WebSocket 监听端口。从 config.go 的参数解析看，未显式指定端口时默认取 80（HTTP）或 443（HTTPS），这里显式指定 8080 便于本地开发。 |
--devconsole | 开启开发者控制台。启动后可直接用浏览器访问http://localhost:8080/count.hs（对应端点路径），获得一个交互式测试界面，无需先写前端 JS 即可验证脚本行为。该参数与--staticdir、--cgidir互斥（见 help.go）。 |
--passenv PATH | 将父进程的PATH环境变量透传给子进程。该参数是本示例能跑起来的先决条件，原因见下文。 |
提示：
./count.hs依赖 shebang 执行，请先确保脚本具有可执行权限（chmod +x count.hs）。
为什么必须--passenv PATH？
原文档特别说明：典型 Haskell 安装中runhaskell并不位于/usr/bin，而更常见于/usr/local/bin。
websocketd 出于安全考虑，对子进程的环境变量采用白名单过滤机制：由 config.go 中的buildParentEnv实现，只把--passenv列出的变量从父进程环境复制给子进程，其余一律清空。默认白名单按平台预设（Linux 为PATH,LD_LIBRARY_PATH，见defaultPassEnv），但如果你机器上的runhaskell位于PATH未覆盖的目录，就必须显式--passenv PATH（甚至追加--passenv PATH=/usr/local/bin这类精确值），否则#!/usr/bin/env runhaskell会因找不到解释器而启动失败。
底层实现可对照 env.go 的createEnv：它会把ParentEnv（来自--passenv）与 CGI 标准变量（REMOTE_ADDR、QUERY_STRING、HTTP_*请求头等）合并后交给子进程。
验证结果
在 devconsole 页面（或任意 WebSocket 客户端）连上ws://localhost:8080/count.hs后，会依次收到 10 条文本消息：1、2、……10，每条间隔约 0.5 秒，随后连接关闭。该行为与仓库根 README.md 中 Bash 版count.sh的快速入门完全一致，只是换成了 Haskell 实现；配套的浏览器前端可参考 examples/html/count.html。
示例二：Greeter——双向请求/应答（源码逐行解析）
greeter.hs 演示的是双向通信：读取客户端发来的每一行，回复一句问候，然后继续等待下一行。
#!/usr/bin/env runhaskell import Control.Monad (unless) import System.IO (hFlush, stdout, stdin, hIsEOF) -- | For each line FOO received on STDIN, respond with "Hello FOO!". main :: IO () main = do eof <- hIsEOF stdin unless eof $ do line <- getLine putStrLn $ "Hello " ++ line ++ "!" hFlush stdout main逐行解读：
hIsEOF stdin：先检查 STDIN 是否已到文件末尾。当 WebSocket 连接关闭时，websocketd 会关闭子进程的 STDIN（详见后文"终止流程"），此时hIsEOF返回True，unless eof让程序自然退出。getLine：从STDIN读取一行——这正是客户端通过 WebSocket 发送过来的消息。在 websocket_endpoint.go 的readFrames中，每条文本消息都会被追加一个\n后再写入子进程 STDIN，保证与getLine的行语义严格对齐。putStrLn $ "Hello " ++ line ++ "!"：把问候语写到 STDOUT（带换行），websocketd 随即作为一条 WebSocket 消息推送给客户端。hFlush stdout：同 Count 示例，强制刷新缓冲区，确保应答即时送达。- 尾递归
main：处理完一行后继续递归调用main，形成"等待输入 → 应答 → 再等待"的持续服务循环。
启动命令
$ websocketd --port=8080 --devconsole --passenv PATH ./greeter.hs参数含义与 Count 示例完全相同。连接ws://localhost:8080/greeter.hs后，发送一行文本websocketd，会立即收到Hello websocketd!；可以持续发送多行，服务端会逐条应答；关闭连接后，hIsEOF stdin变为真，进程优雅退出。
两种示例的语义对比
| 维度 | count.hs | greeter.hs |
|---|---|---|
| 通信方向 | 单向推送（STDOUT → 客户端） | 双向请求/应答（STDIN ↔ STDOUT） |
| 生命周期 | 打印 10 条后自行退出 | 随 WebSocket 连接存活，连接关闭才退出 |
| 关键机制 | threadDelay控制推送节奏 | hIsEOF感知连接关闭 + 尾递归循环 |
原理纵深：websocketd 如何把 STDIN/STDOUT 桥接到 WebSocket
理解底层机制有助于排查"为什么我的 Haskell 脚本收不到消息/推不出去"这类问题。整个桥接由 libwebsocketd 包完成：
- 启动子进程：launcher.go 的
launchCmd用exec.Command启动脚本，并通过StdoutPipe/StderrPipe/StdinPipe建立三条管道，随后交由ProcessEndpoint管理。 - STDOUT 逐行读取：process_endpoint.go 的
readTextOutput用bufio.Reader.ReadBytes('\n')逐行读取子进程输出，去掉行尾的\n（兼容\r\n，见trimEOL）后放入输出通道；配合 endpoint.go 的PipeEndpoints，最终由 websocket_endpoint.go 的Send以一条 WebSocket 文本消息发出。结论：Haskell 侧不hFlush，行数据滞留在进程缓冲区，浏览器端就收不到——这正是两个示例都显式刷新缓冲区的原因。 - STDIN 写入：客户端消息经
readFrames读取后追加\n，再经PipeEndpoints调用ProcessEndpoint.Send写入子进程 STDIN，与 Haskell 的getLine配对。 - 终止流程：process_endpoint.go 的
Terminate采用"逐级升级"策略：先关闭 STDIN（让hIsEOF生效，脚本自行退出）→ 等待closetime（默认 0，即 100ms）→ 未退出则发 SIGINT → SIGTERM → SIGKILL。这与 greeter 示例用hIsEOF优雅退出的设计环环相扣。
这套桥接逻辑在仓库的 process_endpoint_test.go、websocket_endpoint_test.go 等测试文件中有系统验证。
实战建议与常见问题
- 测试先行：websocketd 的哲学是"命令行能跑，WebSocket 就能跑"。先直接运行
./count.hs或./greeter.hs，确认 STDOUT/STDIN 行为符合预期，再挂到 websocketd 下，可快速隔离脚本逻辑与桥接问题。 - 刷新缓冲区是铁律：任何 Haskell WebSocket 脚本都必须对
stdout调用hFlush（或用hSetBuffering stdout NoBuffering关闭缓冲），否则消息不会按行即时推送。 - 善用 devconsole：
--devconsole让每个端点自动获得浏览器测试页，是调试阶段最高效的工具；生产环境再考虑关闭它或改用自定义前端。 - 环境变量白名单：凡脚本运行时依赖的外部命令（解释器、工具链），都要通过
--passenv显式放行，且注意脚本使用#!/usr/bin/env方式查找解释器。 - 连接关闭的感知：需要"连接断开即退出"的脚本（如 greeter），务必在循环开头检查
hIsEOF stdin，避免进程悬挂；websocketd 关闭 STDIN 的时机见前述终止流程。
小结
本文完整复现了 examples/haskell/README.md 中两个官方示例：count.hs演示单向推送与进程自退出，greeter.hs演示逐行双向交互与连接生命周期感知，并逐一说明了--port、--devconsole、--passenv PATH三个参数的作用——其中--passenv PATH是 Haskell 生态下最容易被忽略的启动前提。透过 libwebsocketd 的源码可以看到，这套"按行切割、管道互通、环境白名单"的设计，正是让 Haskell（以及仓库 examples 目录下的十余种语言）零网络依赖即可构建 WebSocket 服务的根本原因。掌握这两个示例，你就掌握了用 Haskell 快速搭建 WebSocket 端点的完整套路。
【免费下载链接】websocketdTurn any program that uses STDIN/STDOUT into a WebSocket server. Like inetd, but for WebSockets.项目地址: https://gitcode.com/gh_mirrors/we/websocketd
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
