简介这份资源汇集了279个开箱即用的Shell脚本覆盖DDoS攻击自动屏蔽、Linux系统邮件告警、MySQL数据库单/多循环备份、Nginx日志按天切割与访问分析、网卡实时流量查看等常见运维场景适合Linux/Unix系统管理员、运维工程师及希望提升脚本能力的初学者参考实践。脚本多以注释和示例参数展示关键命令与逻辑便于理解后直接修改部署。资源包共1个文件为PDF格式整体大小4.69MB内容精炼适合作为Shell编程与自动化运维的速查手册。目前已有154人学习下载适用于需要快速获取现成脚本模板、了解iptables、mysqldump、awk等常用命令组合用法的读者。1. 279个开箱即用的shell脚本拿到手第一件事不是跑而是先盘一遍服务器批量交付、磁盘告警、每天早上要汇总几十个节点的日志时很多人第一反应是去翻现成的 shell 脚本。python 当然也能做但 shell 把系统调用和文本处理揉在一起放哪台机器都能跑代价最低这也是“279个开箱即用的shell脚本(new)2024年新版”这类资源一直有人找的原因。对 shell 脚本入门的同学这套集合的最大价值不是拿来即用的黑匣子而是给你一条从“拿来”到“敢用”的路线挑出其中二三十个看懂逻辑、改掉坏习惯、落到自己机器上跑通然后才谈得上依赖它们。下文不假装见过作者原稿只讲按这套思路整理的脚本集下载之后怎么审、怎么跑、怎么改以及最容易让人翻车的几个地方。2. 先别管 279 这个数字这类脚本集按什么逻辑分类、哪些适合留下来拿到任何一份“开箱即用脚本合集”第一反应都应该是分类而不是逐个点开看。279 个脚本如果按任务平铺真正值得长期维护的可能不超过 30 个。以下分类方式是我在实际项目里验证过的适合大多数运维和后台开发场景。2.1 平铺目录才是能落地的形态公共依赖越少越好我见过不少脚本集想做得很“工程化”弄一个 lib/ 放公共函数库脚本全部 source 它。这种结构在代码评审时好看但拿到生产服务器上就难受你要么把整个目录带着走要么在每台机器上补依赖。开箱即用脚本的真相是单脚本部署。也就是说绝大多数靠谱集合都是平铺的脚本之间不互相引用最多在头部带一个公共函数片段。所以拿到 279 个脚本我先看目录结构。如果目录里大量出现source ./common.sh说明作者把“开箱即用”理解成了“整个仓库克隆下来就能跑”这对单机运维反而是负担。我一般只保留不依赖同目录其他文件的脚本这类脚本拷贝到任意一台机器就能执行才是真正意义上的开箱即用。2.2 值得优先留用的 5 类脚本按任务性质我会把脚本集粗分成以下几类每一类的保留标准和关注点完全不同。类别典型任务主要风险保留建议系统信息采集CPU/内存/磁盘/内核版本一键汇总命令路径在不同发行版不同优先留改造成本低日志处理日志切割、压缩、清理、关键字提取误删风险高路径假设多保留但要加保护变量备份与同步增量备份、远程同步、数据库导出依赖 rsync/mysqldump容易漏配按需留必须先 dry-run网络与连通性ping/nc/curl 探测、端口扫描部分命令没预装输出格式混乱留少量通用性强的文本处理批量替换、CSV 提取、JSON 解析依赖 jq/sed 版本正则差异大逐个读完后保留不要被“279 个”这个数字吓到也不要被它诱惑。真正有用的脚本不会超过三分之一剩下的是历史包袱和重复轮子。shell 脚本的价值在于把重复动作固定下来不在于数量堆砌。2.3 把全量脚本快速盘一遍的关键命令不管脚本来自压缩包还是 git 仓库我都建议先建一个独立目录再做批量检查。以下命令组合是第一步。mkdir -p ~/scripts-candidate tar xf shell-scripts.tar.xz -C ~/scripts-candidate find ~/scripts-candidate -type f -name *.sh | wc -l find ~/scripts-candidate -type f -name *.sh -exec wc -l {} | sort -n | tail -10逻辑说明第一行创建目录第二行解压第三行统计脚本总数第四行按代码行数排序并列出最大的 10 个文件。注意wc -l {} 后面接sort -n排序对象是每个文件的行数总和tail -10取出最长的脚本通常最长的一批就是最值得先读的因为功能完整的脚本一般不会太短而那些 5 行以内的脚本往往是残缺片段。参数说明-exec wc -l {} 中的表示批量传参给 wc比\;高效得多文件名里有空格也能正确处理。解压时用-C指定目录避免解压当前目录后脚本散落一地。这一步跑完你会得到一个最值得精读的文件清单。接下来不要直接双击运行而是进入每一台机器上都要面对的语法和路径问题。3. 下载后的最小试跑环境权限、换行、解释器路径先过三关脚本集走到“能跑”这一步先过三关文件权限、换行符、shebang。这三关任何一关出错看起来都是玄学报错实际原因非常简单。3.1 放进 PATH 之前先放进隔离目录我强烈不建议 279 个脚本一上来就全部放到/usr/local/bin。原因很直白你还没读过它们不知道哪些会覆盖系统命令哪些自带相对路径假设。常见做法是先在~/scripts-candidate里面完成筛选候选脚本单独放到~/scripts/bin再把这个目录加进 PATH。mkdir -p ~/scripts/bin find ~/scripts-candidate -type f -name *.sh -perm /ux -exec cp {} ~/scripts/bin/ \; chmod x ~/scripts/bin/*.sh echo export PATH$HOME/scripts/bin:$PATH ~/.bashrc source ~/.bashrc逻辑说明第一行建目录第二行把已有执行权限的脚本复制出来第三行为没能保留权限的补一次 chmod第四行把目录写进 shell 配置最后让配置生效。这里挑出“已有执行权限”的文件是有意的作者如果连执行权限都没给说明文件可能没经过测试。参数说明find -perm /ux中的/表示“只要 owner 有执行权限就匹配”这是 POSIX 风格比-executable兼容性好-exec cp {}后面要加\;是 find 的标准写法如果写成cp 会收到大量参数在文件名有特殊字符时可能报错。3.2 批量检查文件类型和 shebang别让脚本在解释器上翻车shell 脚本最常见的两种死法第一文件是 CRLF 换行bash 看到^M直接崩溃第二shebang 写死/bin/bash但目标系统上的 bash 在/usr/local/bin/bash。这两类问题都可以在运行前查出来。file ~/scripts/bin/*.sh | grep -v ASCII text | head -20 head -1 ~/scripts/bin/*.sh | grep -E env|/bin/bash|/bin/sh | sort | uniq -c for f in ~/scripts/bin/*.sh; do bash -n $f || echo 语法错误: $f; done逻辑说明file命令能识别脚本是 ASCII 文本还是带 CRLF 的文本grep 反向过滤掉正常文件把异常换行格式直接暴露出来第二行统计所有脚本的 shebang看解释器分布是否统一第三行是语法检查bash -n只解析不执行语法有问题会立刻报错。参数说明grep -v是反向选择输出所有不含 “ASCII text” 的文件如果你看到with CRLF line terminators说明这批脚本来自 Windows 环境head -1后面接grep -E用正则同时匹配三种常见 shebang 写法bash -n的-n是 noexec只做语法解析不实际运行这是避免误操作的底线手段。到这里脚本从“能打开”变成了“语法层面能跑”。但能不能安全跑还需要做静态扫描和试运行隔离。3.3 最小试跑timeout 加 -x先跑无副作用的脚本对任何新脚本我都有一个固定动作用timeout包一层再用bash -x观察执行轨迹最后一把把超时时间压到 10 秒以内。这样即使脚本里有死循环或恶意命令至少不会无限挂起。timeout 10 bash -x ~/scripts/bin/check_disk.sh echo exit code: $?逻辑说明timeout是 GNU coreutils 提供的命令10 秒后强制杀掉进程树bash -x会把每条命令展开后输出到 stderr你能看到脚本真正执行的语句$?拿到退出码124 表示被 timeout 杀掉其他数字是脚本自身的退出状态。参数说明timeout最好加-k 5意思是超时后先发 TERM5 秒还不退就发 KILL防止子进程赖着不走bash -x输出量很大建议配合21 | tail -50使用只看最后 50 行。如果脚本涉及修改系统配置我会在前面加一句export TMPDIR/tmp/scripts-test尽量把临时文件限制在隔离区。4. 让“能跑”变成“敢跑”静态检查、危险命令扫描和试跑沙盒语法通过只是第一关。真正让人放心部署的是让机器替我们做静态检查再把执行环境锁进沙盒最后才谈运行结果。4.1 shellcheck 和 shfmt 是脚本界的代码评审shellcheck 是 shell 脚本静态分析的事实标准shfmt 负责格式化。拿到 279 个脚本我不可能每个都读一遍但机器可以。if command -v shellcheck /dev/null 21; then shellcheck -S warning ~/scripts/bin/*.sh else echo shellcheck 未安装建议先安装 fi逻辑说明command -v先确认 shellcheck 存在避免命令找不到时报错-S warning只显示 warning 及以上级别的问题屏蔽掉 style 级别的噪音。shellcheck 能查出变量未加引号、cd可能失败后继续执行、rm -rf前路径为空等一大批实际问题。参数说明-S是 severity 的缩写可选值有 error、warning、info、style实际使用中 warning 是最合适的档位error 太严容易漏掉有价值的提醒style 太吵。shellcheck 的检查规则是黑盒规则集它不知道脚本的业务上下文所以查出的 warning 需要人工判断但绝大多数提示都指向真实的隐蔽问题。shfmt 的用法通常极其简单shfmt -w -l ~/scripts/bin逻辑说明-w直接写回文件-l会列出需要格式化的文件。这里隐含的意思是先让格式统一再让 shellcheck 查逻辑否则你在看代码时会被缩进问题干扰判断。4.2 危险命令扫描grep 会误伤但不扫描更危险脚本集里最容易出问题的就是带rm -rf、curl ... | sh、mkfs、dd之类操作的脚本。直接用 grep 扫一定会误伤很多注释和字符串但这个动作的价值不是精准而是建立警觉名单。grep -rnE rm[[:space:]]-rf|curl[^|]*\|[[:space:]]*(ba)?sh|mkfs\.|dd[[:space:]]if ~/scripts/bin --include*.sh -l逻辑说明-r递归扫描目录-n显示行号-l只输出文件名正则里把rm -rf的空格用[[:space:]]匹配避免漏掉 tabcurl ... | sh的写法用字符组匹配 bash 或 sh覆盖最常见的管道执行模式dd if是磁盘写入操作一旦出现必须逐行读。参数说明[[:space:]]是 POSIX 字符类比写死空格健壮[^|]*\|[[:space:]]*中的\|在基础正则里表示管道符[^|]*表示管道前任意非管道字符。别只看-l给出的文件名还要用-B5把匹配行前 5 行带出来看上下文否则你看到的 grep 结果可能只是注释里的玩笑。4.3 用临时目录当沙盒把副作用固定在一个地方凡是涉及文件操作的脚本我都会在试跑前把整个环境锁进一个临时目录。这里的思路不是完全禁用脚本写系统路径而是先让脚本在预设路径上把逻辑跑通。TESTROOT/tmp/scripts-sandbox rm -rf $TESTROOT mkdir -p $TESTROOT/var/log $TESTROOT/var/tmp $TESTROOT/work cd $TESTROOT export TMPDIR$TESTROOT/var/tmp timeout 10 bash -x ~/scripts/bin/rotate_logs.sh $TESTROOT/var/log 21 | tail -40逻辑说明第一步定义沙盒根目录rm -rf是为了确保上一次测试的残留不影响结果但注意这里TESTROOT被显式赋值为固定路径所以删除操作是安全的进入沙盒目录后脚本内部的相对路径都会落在沙盒内TMPDIR强制所有临时文件写入沙盒。参数说明rm -rf $TESTROOT之所以敢写是因为变量内容不是空字符串。实际脚本生产环境里我永远会在 rm 之前加一行[ -n $TESTROOT ] || exit 1做空变量保护这是血泪教训等下第 5 章单独讲。4.4 全量语法与 shellcheck 的批量回归沙盒试跑只是抽查最后的批量回归要覆盖全部候选脚本。用一个简单循环把之前的三类检查串起来。for script in ~/scripts/bin/*.sh; do bash -n $script || echo 语法失败: $script command -v shellcheck /dev/null 21 shellcheck -S warning $script done逻辑说明循环对每个脚本先做bash -n语法有问题就打印文件名随后如果有 shellcheck 就继续静态检查。这里注意 shellcheck 的退出码本身非零也不会中断循环因为只决定是否执行 shellcheck 命令不会影响整个 for 循环的结构。参数说明command -v shellcheck /dev/null 21是判断命令是否存在的最标准写法重定向掉所有输出保证了 shellcheck 不存在时不会产生“command not found”噪音。5. 开箱即用脚本的 4 个隐蔽坑CRLF、解释器路径、依赖缺失和 rm -rf到这里脚本基本可以跑了。但真正的生产环境里以下几个坑我几乎每次接手别人的脚本集都会遇到。每条都是真实踩过的格式统一为现象、原因、解决。5.1 CRLF 换行报错随机最像玄学的一类现象脚本解压后直接./script.sh提示bad interpreter: /bin/bash^M: No such file or directory或者运行到一半报$\r: command not found有时候一条命令能跑下一条命令莫名其妙失败。原因脚本在 Windows 上编辑或打包行尾被写成 CRLF。Linux 下的解释器把\r当成命令的一部分第一个命令就崩了。最麻烦的是它不会全部报错只有涉及多行拼接或变量替换的地方才暴露初看非常玄学。解决批量去掉\r不要让用户逐个文件处理。find ~/scripts/bin -name *.sh -exec sed -i s/\r$// {} sed -i s/\r$// ~/scripts/bin/*.sh file ~/scripts/bin/*.sh | grep -c CRLF逻辑说明第一行用 find 配合 sed 批量处理所有.sh文件s/\r$//只删除行尾的回车符不动其他内容第二行是当前目录的兜底写法两层都执行也不会有副作用第三行统计还有多少个文件带 CRLF应该输出 0。参数说明sed -i直接改写文件不同版本的 sed 对-i是否需要后缀参数要求不同GNU sed 直接跟s/...即可BSD sed 会强制要求-i 。如果你在 macOS 上执行要写成sed -i s/\r$//这一点能救很多人一命。5.2 shebang 写死/bin/bash在最小系统和 BSD 上直接断现象脚本在开发机上一切正常发到 Docker 最小镜像或者 FreeBSD/macOS 的机器上执行报错信息可能是/bin/bash: No such file or directory。注意这里的报错主语不是脚本而是解释器本身。原因很多脚本集头部写的是#!/bin/bash这在绝大多数 Linux 发行版成立但 BSD 系和某些精简镜像把 bash 装在/usr/local/bin/bashsystem 默认 shell 还是/bin/sh。写死绝对路径等于放弃跨平台。解决把 shebang 改成环境查找方式同时调整执行时的解释器参数。#!/usr/bin/env bash逻辑说明env命令会在 PATH 里找到第一个 bash然后以它作为解释器执行脚本。这个写法把解释器路径从编译期变成了运行期兼容 Linux 和 BSD 的默认路径差异。参数说明注意#!/usr/bin/env bash不是万能的。有些系统/usr/bin/env不存在或者 PATH 被用户覆盖后指向了奇怪版本。更稳妥的做法是在脚本内部开头加一句if ! command -v bash /dev/null; then exit 1; fi显式声明依赖而不是指望 shebang 自动解决一切。你拿到脚本集时我会用这一条命令批量改掉所有 shebangsed -i 1s|^#!/bin/bash|#!/usr/bin/env bash| ~/scripts/bin/*.sh。5.3 依赖假设jq、nc、rsync 不是每台机器都有现象脚本运行到一半停止不报错也不退出或者输出一堆空行。例如脚本里写jq .data file.json机器上没装 jq命令失败但脚本没有检查退出码后续结果全是空的。原因脚本集合通常在一个“环境完备”的机器上测试作者假设目标机器装了所有依赖但你面前的服务器可能是一个刚初始化的最小镜像连 curl 都要现装。解决写一个依赖检查函数放到所有脚本头部。这是我在脚本集里最常用的一段样板。for dep in jq curl rsync nc; do if ! command -v $dep /dev/null 21; then echo [ERROR] 缺少依赖: $dep 2 exit 1 fi done逻辑说明循环遍历依赖清单command -v检查命令是否存在于 PATH找不到就把错误信息写到 stderr然后退出。注意退出码选择1方便上层调度系统识别。这里2是重定向到标准错误避免和正常输出混在一起。参数说明不要把依赖检查做成硬编码清单建议从脚本参数传入例如check_deps jq curl这样的小函数可以复用。还有一点容易被忽略有些命令本身在但版本太老command -v查不出版本问题。如果脚本用到jq的新语法最好再加一句版本判断例如jq --version | grep -Eo [0-9]\.[0-9]这样版式信息单独校验。5.4 相对路径下的 rm -rf 和覆盖写是 90% 的脚本事故源头现象一个日志清理脚本假设脚本放在/opt/scripts/下里面写了rm -rf logs/$day看起来没问题。但如果哪天你在/home/user下执行这个脚本logs/前缀不存在脚本会直接清理/home/user/logs/如果目录名恰好匹配灾难就发生了。原因脚本作者默认了“当前目录就是脚本目录”或“日志目录相对脚本位置固定”但 shell 的执行环境是由调用者决定的。脚本本身不会自动切换到自身所在目录这是 shell 脚本和编译型语言的最大差别。解决在脚本开头强制切换目录并对所有删除类变量做空值保护。SCRIPT_DIR$(cd $(dirname ${BASH_SOURCE[0]}) pwd) cd $SCRIPT_DIR LOG_DIR${LOG_DIR:?LOG_DIR 未设置} [ -n $LOG_DIR ] || exit 1逻辑说明BASH_SOURCE[0]是脚本自身路径dirname 拿出目录cd 进去再 pwd 拿到绝对路径之后整个脚本的工作目录就固定了LOG_DIR使用了参数展开的:?语法变量为空或未设置时直接报错退出[ -n $LOG_DIR ]是硬保护物理上阻止空字符串传给 rm。这两层保护在一起即使脚本写到rm -rf $LOG_DIR/*也不会出现rm -rf /*的惨案。参数说明${VAR:?message}是 bash 参数展开的特性设置未定义的变量时立刻输出 message 并退出。这个写法只能在 bash 里用如果脚本 shebang 是/bin/sh就要改成显式判断[ -n $LOG_DIR ] || { echo LOG_DIR is empty; exit 1; }。另外对rm -rf的路径我个人的习惯是永远把变量写在{}里例如rm -rf ${LOG_DIR:?}/*这样就算将来有人删掉前面的检查rm 命令本身仍然不会拿到空路径。6. 把 279 个脚本收编成自己的工具箱统一入口、lint 校验、dry-run 验证到了最后一步你要做的不是维护 279 个脚本而是从里面筛出二三十个放进你自己的 bin 目录用统一入口和校验机制长期维护。我自己的习惯是这样先把通过检查的脚本复制到~/scripts/bin再写一个自动加载所有脚本的入口文件把脚本功能映射成短命令。for script in ~/scripts/bin/*.sh; do name$(basename $script .sh) alias $namebash $script done逻辑说明循环遍历所有脚本以文件名作为命令名以bash $script作为别名执行体。这里故意用 bash 显式执行而不是直接./$script是为了绕过文件权限丢失问题也让 shellcheck 在登录时把所有脚本先过一遍语法。参数说明alias 在非交互式 shell 里默认不展开如果你把这些内容写到.bashrc没问题但写进脚本里给别人用建议改用函数$name() { bash $script $; }。函数比 alias 强在支持参数传递$把所有参数原样转发给脚本。答案是这些脚本是不是“new 2024 新版”并不重要重要的是你自己加了什么。我的做法是给每个保留脚本加一个--dry-run参数没有这个参数的脚本一律不放进正式环境。if [[ ${1:-} --dry-run ]]; then export DRY_RUN1 shift fi if [[ ${DRY_RUN:-0} 1 ]]; then echo [DRY RUN] $* exit 0 fi逻辑说明脚本开头检测第一个参数是否为--dry-run是就设置环境变量并跳过 shift 移除该参数执行到真正有副作用的位置时先判断 DRY_RUN 变量为 1 则只打印操作内容并退出。这套模板可以套到任何类型的脚本上让“敢跑”变成“敢批量跑”。参数说明${1:-}和${DRY_RUN:-0}都用了默认值展开避免set -u开启时报变量未定义。注意 dry-run 不要只挡一条命令应该在每个可能造成永久变化的位置都设检查最稳妥的是把真正执行的命令收敛到几个函数里函数开头统一判断。最后说回验证方法。我保留了这样一个固定流程每次修改脚本先跑bash -n再跑shellcheck -S warning然后timeout 10 bash -x 脚本 --dry-run全部通过才进入测试目录。这套流程已经陪我过了几百个脚本至今没有一次因为脚本本身的问题误删除生产数据。真正救我的不是某个脚本写得多么巧妙而是我在最前面拦住了一段没有set -euo pipefail、没有空变量保护、没有切换目录的代码。希望这些从 279 个脚本里筛出来的经验能够帮你在自己的工具箱里踩更少的坑。本文还有配套的精品资源点击获取