使用 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/websocketdwebsocketd 是一款把任何读写 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 解释器 runhaskellcount.hs与greeter.hs的第一行都是#!/usr/bin/env runhaskell即通过系统 PATH 查找runhaskellGHC 自带的脚本解释器来执行脚本无需预编译。典型安装位置是/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 --port8080 --devconsole --passenv PATH ./count.hs三个参数的作用分别是参数作用--port8080指定 HTTP/WebSocket 监听端口。从 config.go 的参数解析看未显式指定端口时默认取 80HTTP或 443HTTPS这里显式指定 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返回Trueunless eof让程序自然退出。getLine从STDIN读取一行——这正是客户端通过 WebSocket 发送过来的消息。在 websocket_endpoint.go 的readFrames中每条文本消息都会被追加一个\n后再写入子进程 STDIN保证与getLine的行语义严格对齐。putStrLn $ Hello line !把问候语写到 STDOUT带换行websocketd 随即作为一条 WebSocket 消息推送给客户端。hFlush stdout同 Count 示例强制刷新缓冲区确保应答即时送达。尾递归main处理完一行后继续递归调用main形成等待输入 → 应答 → 再等待的持续服务循环。启动命令$ websocketd --port8080 --devconsole --passenv PATH ./greeter.hs参数含义与 Count 示例完全相同。连接ws://localhost:8080/greeter.hs后发送一行文本websocketd会立即收到Hello websocketd!可以持续发送多行服务端会逐条应答关闭连接后hIsEOF stdin变为真进程优雅退出。两种示例的语义对比维度count.hsgreeter.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），仅供参考
使用 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/websocketdwebsocketd 是一款把任何读写 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 解释器 runhaskellcount.hs与greeter.hs的第一行都是#!/usr/bin/env runhaskell即通过系统 PATH 查找runhaskellGHC 自带的脚本解释器来执行脚本无需预编译。典型安装位置是/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 --port8080 --devconsole --passenv PATH ./count.hs三个参数的作用分别是参数作用--port8080指定 HTTP/WebSocket 监听端口。从 config.go 的参数解析看未显式指定端口时默认取 80HTTP或 443HTTPS这里显式指定 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返回Trueunless eof让程序自然退出。getLine从STDIN读取一行——这正是客户端通过 WebSocket 发送过来的消息。在 websocket_endpoint.go 的readFrames中每条文本消息都会被追加一个\n后再写入子进程 STDIN保证与getLine的行语义严格对齐。putStrLn $ Hello line !把问候语写到 STDOUT带换行websocketd 随即作为一条 WebSocket 消息推送给客户端。hFlush stdout同 Count 示例强制刷新缓冲区确保应答即时送达。尾递归main处理完一行后继续递归调用main形成等待输入 → 应答 → 再等待的持续服务循环。启动命令$ websocketd --port8080 --devconsole --passenv PATH ./greeter.hs参数含义与 Count 示例完全相同。连接ws://localhost:8080/greeter.hs后发送一行文本websocketd会立即收到Hello websocketd!可以持续发送多行服务端会逐条应答关闭连接后hIsEOF stdin变为真进程优雅退出。两种示例的语义对比维度count.hsgreeter.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），仅供参考
