From dbb54f413483435982750c1c9ba9e4024d942003 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=A4=8F=E7=8A=80=E9=BA=9F?= Date: Mon, 14 Sep 2026 01:11:38 +0800 Subject: [PATCH] =?UTF-8?q?docs:=20=E8=A1=A5=E4=B8=A4=E6=9D=A1=E6=9C=AC?= =?UTF-8?q?=E6=9C=BA=E5=B7=A5=E5=85=B7=E9=93=BE=E5=9D=91=E4=BD=8D=EF=BC=88?= =?UTF-8?q?Grep=20=E4=B8=8D=E6=90=9C=20.workbuddy=E3=80=81Edit=20=E9=9D=99?= =?UTF-8?q?=E9=BB=98=E4=B8=8D=E7=94=9F=E6=95=88=E9=9C=80=E5=9B=9E=E8=AF=BB?= =?UTF-8?q?=EF=BC=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .workbuddy/memory/DEPLOY.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.workbuddy/memory/DEPLOY.md b/.workbuddy/memory/DEPLOY.md index d55e5d0..4f98891 100644 --- a/.workbuddy/memory/DEPLOY.md +++ b/.workbuddy/memory/DEPLOY.md @@ -32,6 +32,8 @@ - **经 `ssh.exe` 执行多行脚本会踩转义坑（2026-09-13 实测）**：把多行 here-string 直接当参数传给 `ssh.exe`，远程 bash 解析到 `(` 等字符会报 `syntax error near unexpected token '('`，**而且报错前的行已经执行了**，导致状态半途而废（证书只搬了一半）。**可靠做法**：本地写 `.sh` 文件（用 `-replace "`r`n","`n"` 强制 LF + `WriteAllText` UTF-8 无 BOM）→ **单独** `scp` 上传 → `ssh "chmod +x /tmp/x.sh && /tmp/x.sh"` 执行。注意 `echo | base64 -d | bash` 会被 PowerShell 工具安全策略直接拦截（"Spawning a non-PowerShell shell"）。 - **多源文件 `scp` 不可靠（2026-09-13 实测）**：一次 `scp a b c d e host:/tmp/` 只落地了其中 2 个，且**没有任何报错**。**每次只 scp 一个文件**；脚本内用 `for` + `[ -f ]` 判断做幂等补齐，避免重复上传。 - **远程脚本一律写成幂等**（`if [ -f ]` 判断后再 `mv -f`），因为 SSH 调用可能被沙箱拦截/用户误拒而中断，重跑不能出错。 +- **Grep 搜不到 `.workbuddy/` 里的内容（2026-09-14 实测）**：Grep 工具（ripgrep）**默认跳过隐藏文件与目录**，`.workbuddy/`、`.gitea/` 这类点开头的目录整个不在搜索范围内 —— 搜项目源码正常，搜 memory/CHANGELOG 会「一个都不匹配」。**别把它当成「文件没改成功」的证据**（曾据此误判为编辑丢失）：验证 `.workbuddy/` 下的改动必须用 Read 直接读。 +- **Edit 会静默不生效**：本项目上出现过多次（尤其目标串含 `_` 下划线的注释、或上下文给得太少时），工具报成功但文件没变。**改完必须回读验证** —— `src/` 下用 Grep，`.workbuddy/` 下用 Read（见上一条）。 - **别用 `echo $LASTEXITCODE` 穿透 ssh 取远端退出码（2026-09-13 实测踩坑）**：`$LASTEXITCODE` 是 PowerShell 自动变量，在**本地**双引号字符串里就被展开成空串，远端实际收到的是 `echo DONE`，于是「脚本明明失败了却看到一个成功的回声」。**可靠做法**：远端 `sh /tmp/x.sh > /tmp/x.log 2>&1`，再 `base64 -w0 /tmp/x.log` 回传、本地解码落盘后用 Read 看（base64 还能顺带规避 Windows 控制台按 GBK 解 UTF-8 造成的乱码）。 - **`set -e` + 写死的路径 = 静默失败**：`kuma-statuspage.sh` 曾把来源文件写死成 `/tmp/wb_kuma_statuspage.sql`，而上传的是 `/tmp/kuma-statuspage.sql`，脚本在第一步就退出，**日志只有一行「缺少 …」，看起来像什么都没发生**。远程脚本内部一律用 `$(dirname "$0")/<同名文件>` 推导，再退到 `/tmp/<同名文件>` 兜底；且上传时保证「脚本名.sh ↔ 同名.sql」成对。 - **SSH 被沙箱拦截时不一定要重试**：先找**公网可达的旁路**做验证。例如 Kuma 的 `/api/status-page/` 在 `status.xpcool.com` 上匿名可达，直接 HTTPS 查就能判断状态页是否建成，省一次权限弹窗。真的需要读远端日志时，再向用户说明并请求重新授权（授权后原命令即可重跑）。