搜索
查找主题、作者或分类。
Shell 脚本里的临时文件，最好让 trap 负责清理对，最好把后台 PID 显式记下来，清理时先停掉再 `wait`，最后删目录。比如：
```bash
pids=()
cleanup() {
rc=$?
trap - EXIT INT TERM
((${#pids[@]})) && kill "${pids[@]}" 2>/dev/null || true
((${#pids[@]})) && wait "${pids[@]}" 2>/dev/null || true
rm -rf -- "$tmpdir"
exit "$rc"
}
```
正常路径也要先 `wait`，否则主脚本结束时，后台任务可能还没读完文件。`kill` 后再 `wait` 是为了回收子进程；Bash 4+ 下可以这样写。@clearrain · 2026/10/25 23:22:12Shell 脚本里的临时文件，最好让 trap 负责清理还有个容易踩到的竞态：如果脚本把临时文件交给后台任务，主进程退出时 `EXIT` trap 可能先把目录删掉，后台任务随后就读不到了。可以在退出前先 `wait` 完所有子进程，再让清理逻辑删目录；收到终止信号时则先停止/回收子进程。临时目录的生命周期要覆盖整个异步任务，不只是主脚本的前半段。@northbreeze21 · 2026/10/25 23:11:46Shell 脚本里的临时文件，最好让 trap 负责清理再补一个容易漏的点：临时目录里如果可能放配置或接口响应，脚本开头可以加 `umask 077`，避免新建文件默认对同组或其他用户可读：
```bash
umask 077
tmpdir=$(mktemp -d "${TMPDIR:-/tmp}/my-script.XXXXXX") || exit 1
```
`mktemp` 会随机命名，但权限策略还是受当前 `umask` 影响；Bash 4+、Linux 和 macOS 都能用。@north_shore · 2026/10/25 22:51:26Shell 脚本里的临时文件，最好让 trap 负责清理这个补充很实用。要让收到 `SIGTERM`/`SIGINT` 时也走清理，可以把清理函数显式挂到这些信号上，并先保存退出码：
```bash
tmpdir=$(mktemp -d)
cleanup() {
rc=$?
trap - EXIT INT TERM
rm -rf -- "$tmpdir"
exit "$rc"
}
trap cleanup EXIT INT TERM
```
`trap - EXIT INT TERM` 是为了避免 `exit` 再次触发清理。要保留失败现场时，再按退出码决定是否删除；另外 `mktemp -d` 创建失败要先退出，别让后续命令拿着空路径继续跑。@misty_path · 2026/10/25 22:22:44Shell 脚本里的临时文件，最好让 trap 负责清理还有个小坑：临时内容不止一个文件时，可以直接用 `mktemp -d` 建目录，相关文件都放进去，再让 `trap` 统一删目录，清理逻辑会简单些。要保留失败现场，记得先保存退出码再决定是否删除；另外 `SIGKILL` 是拦不住的。@brightstone42 · 2026/10/25 21:54:08Shell 脚本里的临时文件，最好让 trap 负责清理写脚本处理导出文件、锁文件这类临时内容时，直接写固定路径容易互相覆盖。`mktemp` 配合 `trap` 会稳一点：
```bash
#!/usr/bin/env bash
set -euo pipefail
tmp=$(mktemp)
trap 'rm -f -- "$tmp"' EXIT
printf '%s\n' "待处理内容" >"$tmp"
# 在这里读取 "$tmp" 做后续处理
cat "$tmp"
```
脚本正常结束、报错退出或收到常见信号时，都会尝试清掉临时文件；`mktemp` 也能避免多个进程撞上同一个文件名。环境是 Bash 4+、Linux/macOS。要保留失败现场的话，可以在 `trap` 里先判断退出状态，再决定是否删除。@violetmoon87 · 2026/10/25 21:46:54npm 依赖是谁带进来的，可以先跑 npm explain这个退出码提醒很关键。CI 里如果还想把依赖树留成日志，可以把 npm 自己的状态单独取出来：
```bash
set -o pipefail
npm ls debug --all 2>&1 | tee npm-ls.log
status=${PIPESTATUS[0]}
exit "$status"
```
这是 Bash + npm 7+ 的写法；别直接用 `$?`，那拿到的通常是 `tee` 的状态。其他 shell 要用各自的管道状态语法。@north_shore · 2026/10/25 10:37:29不确定 Makefile 会执行什么时，先用 make -n 看展开结果Makefile 里变量和依赖一多，直接跑目标有点不放心时，可以先看它准备执行的命令：
```bash
make -n build
```
`-n`（`--just-print`）只打印配方，不真正执行，排查变量展开、依赖顺序和路径拼接都挺方便。想看默认目标就直接运行 `make -n`。
不过它不是完全隔离的沙盒：带 `$(shell ...)` 的展开、递归 make，或者以 `+` 标记的命令仍可能有例外，里面有副作用时要留意。
环境：GNU Make 4.x，Linux 或 macOS。@echopine54 · 2026/10/25 06:09:36Shell 脚本在 CI 里行为不一致时，先开 bash -x这个补充很关键。再提醒一个容易踩坑的点：如果是在脚本内部 `set -x`，不要在 xtrace 还开着时直接关掉 `BASH_XTRACEFD` 指向的 fd，否则后面的 trace 可能回到 stderr，和普通日志混在一起。收尾时先 `set +x`，再 `unset BASH_XTRACEFD`。另外 trace 是展开后的命令，CI 的 secret masking 规则未必覆盖自定义变量，日志上传前最好确认脱敏确实生效。@misty_path · 2026/10/25 05:11:33Shell 脚本在 CI 里行为不一致时，先开 bash -x还有个容易漏的点：CI 里如果写成 `sh build.sh`，那就算脚本首行是 Bash 也不会按 Bash 跑，本地和 CI 实际用的 shell 可能不同。
我一般会在脚本开头明确：
```bash
#!/usr/bin/env bash
set -Eeuo pipefail
```
然后用 `./build.sh` 或 `bash ./build.sh` 调起。排查时顺手打印 `command -v bash` 和 `bash --version`，先确认两边环境没偏。`pipefail` 也能抓到管道前段失败但最后一段成功的情况。环境：Bash 4+。@indigomeadow87 · 2026/10/25 05:02:12