1. 项目概述为什么你需要掌握Shell脚本如果你在Linux或macOS上工作或者哪怕只是偶尔需要处理一些重复性的文件操作、数据备份或者自动化部署任务那么Shell脚本就是你工具箱里最趁手的那把“瑞士军刀”。它不是什么高深莫测的黑科技而是将你日常在终端里敲击的一条条命令按照逻辑顺序组合成一个可重复执行的程序文件。想象一下你每天上班第一件事可能需要登录服务器、检查日志、备份数据库、发送报告邮件。手动操作这些步骤不仅耗时还容易出错。而一个几十行的Shell脚本就能让你在喝第一口咖啡前把这些事全搞定。很多人对Shell脚本望而却步觉得它门槛高或者认为那是运维工程师的专属。其实恰恰相反Shell脚本是进入自动化世界最低成本的入口。你不需要安装庞大的IDE不需要理解复杂的面向对象概念你需要的只是一个文本编辑器比如Vim、Nano甚至记事本和一个能运行Shell的环境。它的核心就是你已经或即将熟悉的那些命令ls、cd、grep、awk、sed... 脚本只是让它们协同工作。从网络上的热门搜索词就能看出大家的痛点所在有人在纠结for循环怎么写有人在为adb shell找不到设备而头疼还有人在各种环境配置错误如npm、opencode命令找不到中挣扎。这些问题很多都可以通过编写一个结构清晰、鲁棒性强的Shell脚本来规避或一键解决。比如那个“一键部署脚本yolo最新版本”的热词背后就是Shell脚本在自动化部署中的典型应用。因此理解Shell脚本的正确编写格式和灵活的执行方式是让你从“命令输入员”进阶为“效率工程师”的关键第一步。这不仅关乎能否运行脚本更关乎你写出的脚本是否健壮、易读、可维护。2. Shell脚本编写格式全解析从“能跑”到“优雅”写一个能运行的Shell脚本很简单但写一个别人包括三个月后的你自己能看懂的脚本就需要遵循一些约定俗成的格式规范。这些规范不是语法强制要求而是无数前辈踩坑后总结的最佳实践能极大提升脚本的质量。2.1 脚本开头的“身份证”Shebang脚本的第一行必须是Shebang#!它告诉系统应该用哪个解释器来执行这个脚本。这是脚本格式的基石。#!/bin/bash这是最常见的形式指定使用Bash解释器。为什么是/bin/bash而不是/bin/sh因为sh通常是bash的符号链接或更简单的Shell如dash而bash支持更多特性如数组、[[ ]]条件测试。为了脚本功能的丰富性和一致性通常直接指定bash。注意事项绝对路径必须使用解释器的绝对路径。#!/bin/bash是正确的#!bash是错误的。环境变量无效不能写成#!/usr/bin/env bash吗可以这在跨平台时更灵活它会去PATH环境变量里查找bash。但在某些严格限制环境或安全要求高的场景如某些Docker基础镜像、嵌入式系统直接使用绝对路径更可靠。对于初学者我建议先坚持使用#!/bin/bash减少一个潜在变量。唯一性Shebang必须是文件的第一行顶格写。前面不能有任何空格或空行。2.2 脚本的“序言”注释与元信息Shebang之后紧接着应该是一段注释块描述脚本的基本信息。这就像产品的说明书至关重要。#!/bin/bash # # 脚本名称daily_backup.sh # 描述用于每日备份指定目录到远程服务器的脚本 # 作者你的名字 # 创建日期2023-10-27 # 版本1.0 # 用法./daily_backup.sh [源目录] [可选备份标签] # 示例./daily_backup.sh /data/project # 为什么需要这个可维护性几个月后你一眼就知道这个脚本是干什么的怎么用。可协作性方便团队成员理解和使用你的脚本。自动化文档可以通过工具提取这些注释生成简易文档。2.3 脚本的“安全与诊断”设置set命令在元信息注释之后正式业务逻辑开始之前强烈建议设置一些Shell选项。这是区分新手和老手的关键一步能避免很多诡异的bug。set -euo pipefail让我们拆解这个“安全三连”set -e 让脚本在任何命令执行失败返回非零状态码时立即退出。想象一下你的脚本第一步是cd /some/dir如果目录不存在脚本本应失败。但没有-e时脚本会继续执行后续命令很可能在错误路径上操作造成破坏。加上-e一旦cd失败脚本立刻停止避免雪崩。set -u 当尝试使用未定义的变量时脚本报错并退出。这能防止因为拼写错误导致的逻辑错误。比如你定义了$source_dir但后面误写成$source_dri没有-u时$source_dri会被当作空字符串脚本静默执行错误逻辑有了-u脚本会直接报错“source_dri: unbound variable”帮你快速定位拼写错误。set -o pipefail 修复管道命令的错误处理。默认情况下管道|中最后一个命令的返回值才是整个管道的返回值。这意味着command1 | command2即使command1失败了只要command2成功整个管道就显示成功。pipefail选项使得管道中任何一个命令失败整个管道的返回值就是失败的那个命令的返回值。这对于错误检查至关重要。实操心得 对于非常重要的生产环境脚本我有时还会加上set -x它会打印出脚本执行的每一行命令展开变量后用于调试。但调试完后通常会注释掉因为输出太详细。你可以通过set -x和set x来只对特定代码块开启调试。2.4 脚本的“身体”变量、函数与主逻辑格式良好的脚本其主体部分也应有清晰的层次。1. 变量定义集中化 将所有可配置的变量集中在脚本前部安全设置之后。使用大写字母和下划线命名这是个好习惯。BACKUP_ROOT/backups LOG_FILE/var/log/mybackup.log MAX_RETAIN_DAYS30注意等号两边不能有空格。Shell的变量赋值语法就是如此。2. 函数定义模块化 将可复用的逻辑封装成函数。函数名使用小写字母和下划线并在函数前写注释说明。# 函数记录日志并打印到标准输出 log_message() { local log_level$1 local message$2 local timestamp$(date %Y-%m-%d %H:%M:%S) echo [${timestamp}] [${log_level}] ${message} | tee -a ${LOG_FILE} } # 函数检查目录是否存在 check_directory() { local dir_to_check$1 if [[ ! -d $dir_to_check ]]; then log_message ERROR 目录不存在${dir_to_check} exit 1 fi }关键点函数内部的变量尽量使用local关键字声明为局部变量避免污染全局命名空间也避免意外的副作用。3. 主逻辑流程清晰化 主逻辑部分通常从main函数开始应该像读文章一样流畅。main() { log_message INFO 备份任务开始 # 1. 检查参数 if [[ $# -lt 1 ]]; then log_message ERROR 用法错误。请提供源目录路径。 echo 用法: $0 源目录 exit 1 fi local source_dir$1 check_directory $source_dir # 2. 创建备份目录 local backup_dir${BACKUP_ROOT}/$(date %Y%m%d) mkdir -p $backup_dir # 3. 执行备份核心操作 log_message INFO 开始备份 ${source_dir} 到 ${backup_dir} if rsync -av --delete $source_dir/ $backup_dir/; then log_message INFO 备份成功。 else log_message ERROR 备份过程中 rsync 命令执行失败。 exit 1 fi # 4. 清理旧备份 cleanup_old_backups log_message INFO 备份任务结束 } # 脚本执行入口 main $格式要点缩进使用4个空格进行缩进Tab键在不同编辑器可能显示不同空格是通用约定。条件判断使用双中括号[[ ]]它比单中括号[ ]功能更强大更安全能防止变量中的空格导致解析错误。变量引用始终用双引号包裹变量如$source_dir。这是防止文件名或路径中含有空格时被Shell错误切分成多个参数的最重要规则搜索词中“shell中常见坑”很多都源于此。错误处理对关键命令如rsync,mkdir进行结果判断失败时记录日志并优雅退出。3. Shell脚本的多种执行方式知其然更知其所以然脚本写好了怎么让它跑起来方法不止一种但每种方法背后都有细微差别理解它们能帮你更好地调试和控制脚本行为。3.1 作为可执行文件直接运行最常用这是最直观的方式前提是脚本有可执行权限。# 1. 首先赋予脚本可执行权限 chmod x your_script.sh # 2. 然后通过路径执行它 ./your_script.sh核心原理 当你输入./your_script.sh并回车时Shell你当前的终端会读取文件的第一行Shebang。看到#!/bin/bash后它就知道“哦这个文件需要交给/bin/bash程序来解释执行”。于是Shell会启动一个新的bash子进程并将脚本文件的内容作为输入传递给这个新的bash进程来逐行执行。为什么是./因为安全原因Shell默认不会在当前目录.中搜索可执行文件。你必须明确指定路径。./代表“当前目录”。如果你把脚本放到了系统PATH环境变量包含的目录如/usr/local/bin就可以像系统命令一样直接your_script.sh运行。3.2 通过指定解释器运行灵活调试这种方式不需要脚本有可执行权限也不需要Shebang行。bash your_script.sh # 或者 sh your_script.sh # 或者使用其他Shell zsh your_script.sh核心原理 你明确告诉系统“请用bash这个程序来运行your_script.sh这个文本文件”。此时bash解释器被启动脚本文件作为其参数被打开并执行。Shebang行在这种情况下会被忽略因为解释器已经由你在命令行指定了。应用场景与对比调试这是最常用的调试方式之一。你可以使用bash -x your_script.sh来运行脚本-x参数会让bash打印出执行的每一行命令展开变量后极其方便定位问题。搜索词中“shell脚本for循环”出问题时用bash -x一看就明白。兼容性测试你可以用sh your_script.sh来测试脚本在更严格的POSIXsh环境下的兼容性。如果你的脚本用了bash特有的语法如[[ ]]、数组用sh运行就会报错这能帮你写出可移植性更好的脚本。忽略权限当脚本没有执行权限或者你只是临时想跑一下不想改权限时这个方法很便捷。3.3 使用source或.命令运行影响当前环境这是一种特殊而重要的执行方式。source your_script.sh # 或者点号是source的简写注意点号后面有空格 . your_script.sh核心原理source命令不会启动一个新的Shell子进程。它指示当前的Shell进程直接读取并执行脚本文件中的命令。这意味着脚本中定义的变量、函数、别名等在执行结束后会保留在当前Shell的环境中。同时脚本中cd命令会改变你当前终端的工作目录。与直接执行./script.sh的对比实验创建一个脚本test_env.sh#!/bin/bash MY_VARHello from Script cd /tmp pwd在终端中实验# 实验1直接执行子进程模式 $ ./test_env.sh /tmp # 子进程中 pwd 的输出 $ echo $MY_VAR (空) # 变量不存在于当前Shell $ pwd /home/yourname # 当前Shell的工作目录没变 # 实验2使用 source 执行当前进程模式 $ source test_env.sh /tmp # 当前Shell中 pwd 的输出 $ echo $MY_VAR Hello from Script # 变量存在于当前Shell了 $ pwd /tmp # 当前Shell的工作目录被改变了应用场景加载环境配置最常见的用途。比如你的~/.bashrc或~/.bash_profile文件就是被Shell在启动时source的从而将其中定义的环境变量、别名、函数加载到当前会话。函数库将一组常用的函数写在一个脚本里例如my_lib.sh然后在其他脚本或终端中通过source my_lib.sh来导入这些函数就像import一样。排查“找不到命令”当你在脚本或终端遇到“npm : 无法将“npm”项识别为 cmdlet、函数、脚本文件或可运行程序的名称”这类错误时通常是因为环境变量PATH没设置对。你可以写一个脚本设置正确的PATH然后用source执行它使其立即生效而无需重启终端。注意事项 正因为source会改变当前环境所以千万不要随意source来历不明的脚本它有潜在安全风险。同时搜索词中“-sh: 26: source: not found”这个错误通常发生在你用sh可能是dash去执行一个包含source命令的脚本而dash并不识别source关键字它只认.。这时需要将脚本首行的Shebang改为#!/bin/bash或者将source改为点号.。4. 执行方式深入参数、环境与进程理解了基本执行方式我们再来深入看看脚本运行时的一些关键概念这些是解决复杂问题的基石。4.1 脚本如何接收参数$0,$1,$2...$,$*脚本可以像命令一样接受参数。这些参数在脚本内部通过特殊变量来访问。#!/bin/bash # 脚本名arg_demo.sh echo “脚本名称$0” echo “第一个参数$1” echo “第二个参数$2” echo “所有参数每个参数独立$” echo “所有参数合并成一个字符串$*” echo “参数总个数$#”执行./arg_demo.sh apple banana cherry输出脚本名称./arg_demo.sh 第一个参数apple 第二个参数banana 所有参数每个参数独立apple banana cherry 所有参数合并成一个字符串apple banana cherry 参数总个数3$vs$*的微妙区别 在大多数情况下它们看起来一样但在被双引号引用时行为不同这对于将参数传递给其他命令至关重要。#!/bin/bash # 脚本名quote_demo.sh echo “使用 \$:” for arg in “$”; do echo “[$arg]” done echo “使用 \$*:” for arg in “$*”; do echo “[$arg]” done执行./quote_demo.sh a b “c d”输出使用 $: [a] [b] [c d] # 注意“c d”作为一个整体被保留了 使用 $*: [a b c d] # 所有参数被合并成了一个字符串实操心得在需要循环处理所有参数或者将参数原封不动地传递给内部命令如docker run ...时永远使用“$”。这是最安全、最符合直觉的方式。4.2 子Shell与独立进程空间当通过./script.sh或bash script.sh方式执行时脚本是在一个全新的子Shell子进程中运行的。这个子进程会继承父Shell的环境变量用export导出的变量但不会继承父Shell的普通Shell变量和函数除非用export -f导出函数但这不常见。子进程对自身环境的任何修改如定义新变量、cd切换目录在脚本执行结束后都会随着子进程的消亡而消失不会影响父Shell。这就是为什么你无法在脚本中直接改变父终端工作目录的原因。如果你需要脚本执行结果影响当前环境就必须使用source。4.3 环境变量与脚本配置环境变量是Shell脚本中重要的配置来源。它们可以从父进程继承也可以在脚本中临时设置。#!/bin/bash # 使用预定义的环境变量 echo “当前用户$USER” echo “家目录$HOME” echo “路径变量$PATH” # 设置临时环境变量仅在此脚本及其子进程中有效 export TEMP_VAR“some_value” # 或者只对后续命令生效不导出 ANOTHER_VAR“another_value” # 调用其他命令该命令能获取到 TEMP_VAR some_command一个常见问题排查 搜索词中“npm : 无法将“npm”项识别为 cmdlet、函数、脚本文件或可运行程序的名称”这个Windows PowerShell错误其Linux/macOS Shell版本就是“command not found”。这几乎总是因为PATH环境变量中没有包含该命令所在的目录。解决方法临时解决在当前Shell中直接设置PATH。export PATH“/path/to/node/bin:$PATH”永久解决将上面的export行添加到你的Shell配置文件~/.bashrc,~/.zshrc等中然后source ~/.bashrc使其生效。5. 高级执行技巧与实战场景掌握了基础我们来看一些更贴近实战的高级技巧和场景这些能让你写的脚本更加健壮和强大。5.1 后台执行与输出重定向有时你需要脚本在后台运行不占用当前终端。# 在后台运行脚本并将标准输出和标准错误都重定向到 log.txt 文件 ./long_running_task.sh log.txt 21 将标准输出重定向到文件覆盖。21 将标准错误重定向到标准输出。2代表文件描述符2标准错误1代表文件描述符1标准输出。1表示指向标准输出当前指向的位置即log.txt。 放在命令末尾表示在后台运行。组合起来就是将脚本的所有输出正常和错误都追加到log.txt并且不阻塞当前终端。查看和管理后台任务jobs -l # 查看当前Shell的后台任务及其进程号 fg %1 # 将1号后台任务调到前台运行 bg %1 # 将暂停的1号任务在后台继续运行 kill %1 # 终止1号后台任务5.2 脚本的嵌套与模块化调用复杂的任务可以通过多个脚本分工协作。主脚本调用子脚本#!/bin/bash # main_script.sh set -e echo “主脚本开始” # 调用子脚本并检查其返回值 if ./sub_task_1.sh; then echo “子任务1成功” else echo “子任务1失败主脚本退出” exit 1 fi # 另一种方式捕获子脚本输出 output$(./sub_task_2.sh) echo “子任务2的输出是$output”子脚本(sub_task_1.sh) 应该通过返回状态码0表示成功非0表示失败来告知主脚本执行结果。5.3 处理信号与优雅退出脚本可能会被用户中断CtrlC我们需要处理这种信号做一些清理工作。#!/bin/bash # trap_demo.sh # 定义清理函数 cleanup() { echo “捕获到中断信号正在清理临时文件...” rm -f /tmp/my_temp_*.txt echo “清理完成退出。” exit 1 } # 使用 trap 命令捕获 SIGINT (CtrlC) 和 SIGTERM (kill命令) 信号并执行 cleanup 函数 trap cleanup SIGINT SIGTERM echo “脚本开始运行按 CtrlC 中断...” # 模拟一个长时间运行的任务 count1 while true; do echo “运行中... ${count}” “/tmp/my_temp_${count}.txt” sleep 2 ((count)) done运行这个脚本并按CtrlC你会看到它先执行了cleanup函数里的清理动作然后才退出。这对于需要释放资源如删除锁文件、关闭网络连接的脚本非常重要。5.4 实战场景一个健壮的目录备份脚本结合以上所有知识点我们来看一个接近生产环境的简单示例。#!/bin/bash # robust_backup.sh # 描述带错误处理、日志和锁机制的目录备份脚本 set -euo pipefail # 配置区 readonly BACKUP_BASE“/data/backups” readonly SOURCE_DIR“/data/app/logs” readonly LOG_FILE“/var/log/robust_backup.log” readonly LOCK_FILE“/tmp/robust_backup.lock” readonly MAX_RETAIN_DAYS7 # 函数定义区 # 日志函数 log() { local level“$1” local msg“$2” echo “[$(date ‘%Y-%m-%d %H:%M:%S’)] [${level}] ${msg}” | tee -a “${LOG_FILE}” } # 错误处理与退出函数 die() { log “ERROR” “$1” # 如果存在锁文件则清理 [[ -f “${LOCK_FILE}” ]] rm -f “${LOCK_FILE}” exit 1 } # 检查并创建锁 acquire_lock() { if [[ -f “${LOCK_FILE}” ]]; then # 检查锁是否过期例如进程可能已崩溃 local pid$(cat “${LOCK_FILE}” 2/dev/null) if kill -0 “$pid” 2/dev/null; then die “备份进程 (PID: ${pid}) 正在运行请勿重复执行。” else log “WARN” “发现陈旧的锁文件正在清理。” rm -f “${LOCK_FILE}” fi fi echo $$ “${LOCK_FILE}” # $$ 是当前脚本的进程ID } # 释放锁 release_lock() { rm -f “${LOCK_FILE}” } # 清理旧备份 cleanup_old_backups() { log “INFO” “开始清理超过 ${MAX_RETAIN_DAYS} 天的旧备份...” find “${BACKUP_BASE}” -name “backup_*” -type d -mtime “${MAX_RETAIN_DAYS}” | while read -r old_dir; do log “INFO” “删除旧备份目录${old_dir}” rm -rf “${old_dir}” done } # 主函数 main() { log “INFO” “ 备份任务启动 ” acquire_lock # 检查源目录 if [[ ! -d “${SOURCE_DIR}” ]]; then die “源目录不存在${SOURCE_DIR}” fi # 创建备份目录 local backup_dir“${BACKUP_BASE}/backup_$(date %Y%m%d_%H%M%S)” if ! mkdir -p “${backup_dir}”; then die “无法创建备份目录${backup_dir}” fi log “INFO” “备份目标目录${backup_dir}” # 执行备份使用 rsync log “INFO” “开始同步数据...” if rsync -av --delete “${SOURCE_DIR}/” “${backup_dir}/” “${LOG_FILE}” 21; then log “INFO” “数据同步成功。” else die “rsync 同步失败详情请查看日志${LOG_FILE}” fi # 生成备份摘要 local backup_size$(du -sh “${backup_dir}” | cut -f1) log “INFO” “备份完成。目录${backup_dir} 大小${backup_size}” # 清理旧备份 cleanup_old_backups log “INFO” “ 备份任务成功结束 ” release_lock } # 脚本入口 # 捕获退出信号确保锁被释放 trap ‘release_lock; log “WARN” “脚本被中断。”; exit 1’ INT TERM main这个脚本体现了多个重要实践安全设置set -euo pipefail。只读变量使用readonly防止意外修改配置。全面的日志所有操作都有日志并同时输出到屏幕和文件。锁机制防止脚本并发执行导致数据错乱。信号捕获使用trap确保即使被中断锁文件也能被清理。详细的错误处理每一步都检查是否成功失败则调用die函数优雅退出。资源清理备份后自动清理旧数据。你可以通过./robust_backup.sh来执行它它会自动处理所有细节。这个脚本的框架可以很容易地适配到其他备份或定时任务场景。 Shell脚本编写与执行全解析：从基础格式到高级实战
1. 项目概述为什么你需要掌握Shell脚本如果你在Linux或macOS上工作或者哪怕只是偶尔需要处理一些重复性的文件操作、数据备份或者自动化部署任务那么Shell脚本就是你工具箱里最趁手的那把“瑞士军刀”。它不是什么高深莫测的黑科技而是将你日常在终端里敲击的一条条命令按照逻辑顺序组合成一个可重复执行的程序文件。想象一下你每天上班第一件事可能需要登录服务器、检查日志、备份数据库、发送报告邮件。手动操作这些步骤不仅耗时还容易出错。而一个几十行的Shell脚本就能让你在喝第一口咖啡前把这些事全搞定。很多人对Shell脚本望而却步觉得它门槛高或者认为那是运维工程师的专属。其实恰恰相反Shell脚本是进入自动化世界最低成本的入口。你不需要安装庞大的IDE不需要理解复杂的面向对象概念你需要的只是一个文本编辑器比如Vim、Nano甚至记事本和一个能运行Shell的环境。它的核心就是你已经或即将熟悉的那些命令ls、cd、grep、awk、sed... 脚本只是让它们协同工作。从网络上的热门搜索词就能看出大家的痛点所在有人在纠结for循环怎么写有人在为adb shell找不到设备而头疼还有人在各种环境配置错误如npm、opencode命令找不到中挣扎。这些问题很多都可以通过编写一个结构清晰、鲁棒性强的Shell脚本来规避或一键解决。比如那个“一键部署脚本yolo最新版本”的热词背后就是Shell脚本在自动化部署中的典型应用。因此理解Shell脚本的正确编写格式和灵活的执行方式是让你从“命令输入员”进阶为“效率工程师”的关键第一步。这不仅关乎能否运行脚本更关乎你写出的脚本是否健壮、易读、可维护。2. Shell脚本编写格式全解析从“能跑”到“优雅”写一个能运行的Shell脚本很简单但写一个别人包括三个月后的你自己能看懂的脚本就需要遵循一些约定俗成的格式规范。这些规范不是语法强制要求而是无数前辈踩坑后总结的最佳实践能极大提升脚本的质量。2.1 脚本开头的“身份证”Shebang脚本的第一行必须是Shebang#!它告诉系统应该用哪个解释器来执行这个脚本。这是脚本格式的基石。#!/bin/bash这是最常见的形式指定使用Bash解释器。为什么是/bin/bash而不是/bin/sh因为sh通常是bash的符号链接或更简单的Shell如dash而bash支持更多特性如数组、[[ ]]条件测试。为了脚本功能的丰富性和一致性通常直接指定bash。注意事项绝对路径必须使用解释器的绝对路径。#!/bin/bash是正确的#!bash是错误的。环境变量无效不能写成#!/usr/bin/env bash吗可以这在跨平台时更灵活它会去PATH环境变量里查找bash。但在某些严格限制环境或安全要求高的场景如某些Docker基础镜像、嵌入式系统直接使用绝对路径更可靠。对于初学者我建议先坚持使用#!/bin/bash减少一个潜在变量。唯一性Shebang必须是文件的第一行顶格写。前面不能有任何空格或空行。2.2 脚本的“序言”注释与元信息Shebang之后紧接着应该是一段注释块描述脚本的基本信息。这就像产品的说明书至关重要。#!/bin/bash # # 脚本名称daily_backup.sh # 描述用于每日备份指定目录到远程服务器的脚本 # 作者你的名字 # 创建日期2023-10-27 # 版本1.0 # 用法./daily_backup.sh [源目录] [可选备份标签] # 示例./daily_backup.sh /data/project # 为什么需要这个可维护性几个月后你一眼就知道这个脚本是干什么的怎么用。可协作性方便团队成员理解和使用你的脚本。自动化文档可以通过工具提取这些注释生成简易文档。2.3 脚本的“安全与诊断”设置set命令在元信息注释之后正式业务逻辑开始之前强烈建议设置一些Shell选项。这是区分新手和老手的关键一步能避免很多诡异的bug。set -euo pipefail让我们拆解这个“安全三连”set -e 让脚本在任何命令执行失败返回非零状态码时立即退出。想象一下你的脚本第一步是cd /some/dir如果目录不存在脚本本应失败。但没有-e时脚本会继续执行后续命令很可能在错误路径上操作造成破坏。加上-e一旦cd失败脚本立刻停止避免雪崩。set -u 当尝试使用未定义的变量时脚本报错并退出。这能防止因为拼写错误导致的逻辑错误。比如你定义了$source_dir但后面误写成$source_dri没有-u时$source_dri会被当作空字符串脚本静默执行错误逻辑有了-u脚本会直接报错“source_dri: unbound variable”帮你快速定位拼写错误。set -o pipefail 修复管道命令的错误处理。默认情况下管道|中最后一个命令的返回值才是整个管道的返回值。这意味着command1 | command2即使command1失败了只要command2成功整个管道就显示成功。pipefail选项使得管道中任何一个命令失败整个管道的返回值就是失败的那个命令的返回值。这对于错误检查至关重要。实操心得 对于非常重要的生产环境脚本我有时还会加上set -x它会打印出脚本执行的每一行命令展开变量后用于调试。但调试完后通常会注释掉因为输出太详细。你可以通过set -x和set x来只对特定代码块开启调试。2.4 脚本的“身体”变量、函数与主逻辑格式良好的脚本其主体部分也应有清晰的层次。1. 变量定义集中化 将所有可配置的变量集中在脚本前部安全设置之后。使用大写字母和下划线命名这是个好习惯。BACKUP_ROOT/backups LOG_FILE/var/log/mybackup.log MAX_RETAIN_DAYS30注意等号两边不能有空格。Shell的变量赋值语法就是如此。2. 函数定义模块化 将可复用的逻辑封装成函数。函数名使用小写字母和下划线并在函数前写注释说明。# 函数记录日志并打印到标准输出 log_message() { local log_level$1 local message$2 local timestamp$(date %Y-%m-%d %H:%M:%S) echo [${timestamp}] [${log_level}] ${message} | tee -a ${LOG_FILE} } # 函数检查目录是否存在 check_directory() { local dir_to_check$1 if [[ ! -d $dir_to_check ]]; then log_message ERROR 目录不存在${dir_to_check} exit 1 fi }关键点函数内部的变量尽量使用local关键字声明为局部变量避免污染全局命名空间也避免意外的副作用。3. 主逻辑流程清晰化 主逻辑部分通常从main函数开始应该像读文章一样流畅。main() { log_message INFO 备份任务开始 # 1. 检查参数 if [[ $# -lt 1 ]]; then log_message ERROR 用法错误。请提供源目录路径。 echo 用法: $0 源目录 exit 1 fi local source_dir$1 check_directory $source_dir # 2. 创建备份目录 local backup_dir${BACKUP_ROOT}/$(date %Y%m%d) mkdir -p $backup_dir # 3. 执行备份核心操作 log_message INFO 开始备份 ${source_dir} 到 ${backup_dir} if rsync -av --delete $source_dir/ $backup_dir/; then log_message INFO 备份成功。 else log_message ERROR 备份过程中 rsync 命令执行失败。 exit 1 fi # 4. 清理旧备份 cleanup_old_backups log_message INFO 备份任务结束 } # 脚本执行入口 main $格式要点缩进使用4个空格进行缩进Tab键在不同编辑器可能显示不同空格是通用约定。条件判断使用双中括号[[ ]]它比单中括号[ ]功能更强大更安全能防止变量中的空格导致解析错误。变量引用始终用双引号包裹变量如$source_dir。这是防止文件名或路径中含有空格时被Shell错误切分成多个参数的最重要规则搜索词中“shell中常见坑”很多都源于此。错误处理对关键命令如rsync,mkdir进行结果判断失败时记录日志并优雅退出。3. Shell脚本的多种执行方式知其然更知其所以然脚本写好了怎么让它跑起来方法不止一种但每种方法背后都有细微差别理解它们能帮你更好地调试和控制脚本行为。3.1 作为可执行文件直接运行最常用这是最直观的方式前提是脚本有可执行权限。# 1. 首先赋予脚本可执行权限 chmod x your_script.sh # 2. 然后通过路径执行它 ./your_script.sh核心原理 当你输入./your_script.sh并回车时Shell你当前的终端会读取文件的第一行Shebang。看到#!/bin/bash后它就知道“哦这个文件需要交给/bin/bash程序来解释执行”。于是Shell会启动一个新的bash子进程并将脚本文件的内容作为输入传递给这个新的bash进程来逐行执行。为什么是./因为安全原因Shell默认不会在当前目录.中搜索可执行文件。你必须明确指定路径。./代表“当前目录”。如果你把脚本放到了系统PATH环境变量包含的目录如/usr/local/bin就可以像系统命令一样直接your_script.sh运行。3.2 通过指定解释器运行灵活调试这种方式不需要脚本有可执行权限也不需要Shebang行。bash your_script.sh # 或者 sh your_script.sh # 或者使用其他Shell zsh your_script.sh核心原理 你明确告诉系统“请用bash这个程序来运行your_script.sh这个文本文件”。此时bash解释器被启动脚本文件作为其参数被打开并执行。Shebang行在这种情况下会被忽略因为解释器已经由你在命令行指定了。应用场景与对比调试这是最常用的调试方式之一。你可以使用bash -x your_script.sh来运行脚本-x参数会让bash打印出执行的每一行命令展开变量后极其方便定位问题。搜索词中“shell脚本for循环”出问题时用bash -x一看就明白。兼容性测试你可以用sh your_script.sh来测试脚本在更严格的POSIXsh环境下的兼容性。如果你的脚本用了bash特有的语法如[[ ]]、数组用sh运行就会报错这能帮你写出可移植性更好的脚本。忽略权限当脚本没有执行权限或者你只是临时想跑一下不想改权限时这个方法很便捷。3.3 使用source或.命令运行影响当前环境这是一种特殊而重要的执行方式。source your_script.sh # 或者点号是source的简写注意点号后面有空格 . your_script.sh核心原理source命令不会启动一个新的Shell子进程。它指示当前的Shell进程直接读取并执行脚本文件中的命令。这意味着脚本中定义的变量、函数、别名等在执行结束后会保留在当前Shell的环境中。同时脚本中cd命令会改变你当前终端的工作目录。与直接执行./script.sh的对比实验创建一个脚本test_env.sh#!/bin/bash MY_VARHello from Script cd /tmp pwd在终端中实验# 实验1直接执行子进程模式 $ ./test_env.sh /tmp # 子进程中 pwd 的输出 $ echo $MY_VAR (空) # 变量不存在于当前Shell $ pwd /home/yourname # 当前Shell的工作目录没变 # 实验2使用 source 执行当前进程模式 $ source test_env.sh /tmp # 当前Shell中 pwd 的输出 $ echo $MY_VAR Hello from Script # 变量存在于当前Shell了 $ pwd /tmp # 当前Shell的工作目录被改变了应用场景加载环境配置最常见的用途。比如你的~/.bashrc或~/.bash_profile文件就是被Shell在启动时source的从而将其中定义的环境变量、别名、函数加载到当前会话。函数库将一组常用的函数写在一个脚本里例如my_lib.sh然后在其他脚本或终端中通过source my_lib.sh来导入这些函数就像import一样。排查“找不到命令”当你在脚本或终端遇到“npm : 无法将“npm”项识别为 cmdlet、函数、脚本文件或可运行程序的名称”这类错误时通常是因为环境变量PATH没设置对。你可以写一个脚本设置正确的PATH然后用source执行它使其立即生效而无需重启终端。注意事项 正因为source会改变当前环境所以千万不要随意source来历不明的脚本它有潜在安全风险。同时搜索词中“-sh: 26: source: not found”这个错误通常发生在你用sh可能是dash去执行一个包含source命令的脚本而dash并不识别source关键字它只认.。这时需要将脚本首行的Shebang改为#!/bin/bash或者将source改为点号.。4. 执行方式深入参数、环境与进程理解了基本执行方式我们再来深入看看脚本运行时的一些关键概念这些是解决复杂问题的基石。4.1 脚本如何接收参数$0,$1,$2...$,$*脚本可以像命令一样接受参数。这些参数在脚本内部通过特殊变量来访问。#!/bin/bash # 脚本名arg_demo.sh echo “脚本名称$0” echo “第一个参数$1” echo “第二个参数$2” echo “所有参数每个参数独立$” echo “所有参数合并成一个字符串$*” echo “参数总个数$#”执行./arg_demo.sh apple banana cherry输出脚本名称./arg_demo.sh 第一个参数apple 第二个参数banana 所有参数每个参数独立apple banana cherry 所有参数合并成一个字符串apple banana cherry 参数总个数3$vs$*的微妙区别 在大多数情况下它们看起来一样但在被双引号引用时行为不同这对于将参数传递给其他命令至关重要。#!/bin/bash # 脚本名quote_demo.sh echo “使用 \$:” for arg in “$”; do echo “[$arg]” done echo “使用 \$*:” for arg in “$*”; do echo “[$arg]” done执行./quote_demo.sh a b “c d”输出使用 $: [a] [b] [c d] # 注意“c d”作为一个整体被保留了 使用 $*: [a b c d] # 所有参数被合并成了一个字符串实操心得在需要循环处理所有参数或者将参数原封不动地传递给内部命令如docker run ...时永远使用“$”。这是最安全、最符合直觉的方式。4.2 子Shell与独立进程空间当通过./script.sh或bash script.sh方式执行时脚本是在一个全新的子Shell子进程中运行的。这个子进程会继承父Shell的环境变量用export导出的变量但不会继承父Shell的普通Shell变量和函数除非用export -f导出函数但这不常见。子进程对自身环境的任何修改如定义新变量、cd切换目录在脚本执行结束后都会随着子进程的消亡而消失不会影响父Shell。这就是为什么你无法在脚本中直接改变父终端工作目录的原因。如果你需要脚本执行结果影响当前环境就必须使用source。4.3 环境变量与脚本配置环境变量是Shell脚本中重要的配置来源。它们可以从父进程继承也可以在脚本中临时设置。#!/bin/bash # 使用预定义的环境变量 echo “当前用户$USER” echo “家目录$HOME” echo “路径变量$PATH” # 设置临时环境变量仅在此脚本及其子进程中有效 export TEMP_VAR“some_value” # 或者只对后续命令生效不导出 ANOTHER_VAR“another_value” # 调用其他命令该命令能获取到 TEMP_VAR some_command一个常见问题排查 搜索词中“npm : 无法将“npm”项识别为 cmdlet、函数、脚本文件或可运行程序的名称”这个Windows PowerShell错误其Linux/macOS Shell版本就是“command not found”。这几乎总是因为PATH环境变量中没有包含该命令所在的目录。解决方法临时解决在当前Shell中直接设置PATH。export PATH“/path/to/node/bin:$PATH”永久解决将上面的export行添加到你的Shell配置文件~/.bashrc,~/.zshrc等中然后source ~/.bashrc使其生效。5. 高级执行技巧与实战场景掌握了基础我们来看一些更贴近实战的高级技巧和场景这些能让你写的脚本更加健壮和强大。5.1 后台执行与输出重定向有时你需要脚本在后台运行不占用当前终端。# 在后台运行脚本并将标准输出和标准错误都重定向到 log.txt 文件 ./long_running_task.sh log.txt 21 将标准输出重定向到文件覆盖。21 将标准错误重定向到标准输出。2代表文件描述符2标准错误1代表文件描述符1标准输出。1表示指向标准输出当前指向的位置即log.txt。 放在命令末尾表示在后台运行。组合起来就是将脚本的所有输出正常和错误都追加到log.txt并且不阻塞当前终端。查看和管理后台任务jobs -l # 查看当前Shell的后台任务及其进程号 fg %1 # 将1号后台任务调到前台运行 bg %1 # 将暂停的1号任务在后台继续运行 kill %1 # 终止1号后台任务5.2 脚本的嵌套与模块化调用复杂的任务可以通过多个脚本分工协作。主脚本调用子脚本#!/bin/bash # main_script.sh set -e echo “主脚本开始” # 调用子脚本并检查其返回值 if ./sub_task_1.sh; then echo “子任务1成功” else echo “子任务1失败主脚本退出” exit 1 fi # 另一种方式捕获子脚本输出 output$(./sub_task_2.sh) echo “子任务2的输出是$output”子脚本(sub_task_1.sh) 应该通过返回状态码0表示成功非0表示失败来告知主脚本执行结果。5.3 处理信号与优雅退出脚本可能会被用户中断CtrlC我们需要处理这种信号做一些清理工作。#!/bin/bash # trap_demo.sh # 定义清理函数 cleanup() { echo “捕获到中断信号正在清理临时文件...” rm -f /tmp/my_temp_*.txt echo “清理完成退出。” exit 1 } # 使用 trap 命令捕获 SIGINT (CtrlC) 和 SIGTERM (kill命令) 信号并执行 cleanup 函数 trap cleanup SIGINT SIGTERM echo “脚本开始运行按 CtrlC 中断...” # 模拟一个长时间运行的任务 count1 while true; do echo “运行中... ${count}” “/tmp/my_temp_${count}.txt” sleep 2 ((count)) done运行这个脚本并按CtrlC你会看到它先执行了cleanup函数里的清理动作然后才退出。这对于需要释放资源如删除锁文件、关闭网络连接的脚本非常重要。5.4 实战场景一个健壮的目录备份脚本结合以上所有知识点我们来看一个接近生产环境的简单示例。#!/bin/bash # robust_backup.sh # 描述带错误处理、日志和锁机制的目录备份脚本 set -euo pipefail # 配置区 readonly BACKUP_BASE“/data/backups” readonly SOURCE_DIR“/data/app/logs” readonly LOG_FILE“/var/log/robust_backup.log” readonly LOCK_FILE“/tmp/robust_backup.lock” readonly MAX_RETAIN_DAYS7 # 函数定义区 # 日志函数 log() { local level“$1” local msg“$2” echo “[$(date ‘%Y-%m-%d %H:%M:%S’)] [${level}] ${msg}” | tee -a “${LOG_FILE}” } # 错误处理与退出函数 die() { log “ERROR” “$1” # 如果存在锁文件则清理 [[ -f “${LOCK_FILE}” ]] rm -f “${LOCK_FILE}” exit 1 } # 检查并创建锁 acquire_lock() { if [[ -f “${LOCK_FILE}” ]]; then # 检查锁是否过期例如进程可能已崩溃 local pid$(cat “${LOCK_FILE}” 2/dev/null) if kill -0 “$pid” 2/dev/null; then die “备份进程 (PID: ${pid}) 正在运行请勿重复执行。” else log “WARN” “发现陈旧的锁文件正在清理。” rm -f “${LOCK_FILE}” fi fi echo $$ “${LOCK_FILE}” # $$ 是当前脚本的进程ID } # 释放锁 release_lock() { rm -f “${LOCK_FILE}” } # 清理旧备份 cleanup_old_backups() { log “INFO” “开始清理超过 ${MAX_RETAIN_DAYS} 天的旧备份...” find “${BACKUP_BASE}” -name “backup_*” -type d -mtime “${MAX_RETAIN_DAYS}” | while read -r old_dir; do log “INFO” “删除旧备份目录${old_dir}” rm -rf “${old_dir}” done } # 主函数 main() { log “INFO” “ 备份任务启动 ” acquire_lock # 检查源目录 if [[ ! -d “${SOURCE_DIR}” ]]; then die “源目录不存在${SOURCE_DIR}” fi # 创建备份目录 local backup_dir“${BACKUP_BASE}/backup_$(date %Y%m%d_%H%M%S)” if ! mkdir -p “${backup_dir}”; then die “无法创建备份目录${backup_dir}” fi log “INFO” “备份目标目录${backup_dir}” # 执行备份使用 rsync log “INFO” “开始同步数据...” if rsync -av --delete “${SOURCE_DIR}/” “${backup_dir}/” “${LOG_FILE}” 21; then log “INFO” “数据同步成功。” else die “rsync 同步失败详情请查看日志${LOG_FILE}” fi # 生成备份摘要 local backup_size$(du -sh “${backup_dir}” | cut -f1) log “INFO” “备份完成。目录${backup_dir} 大小${backup_size}” # 清理旧备份 cleanup_old_backups log “INFO” “ 备份任务成功结束 ” release_lock } # 脚本入口 # 捕获退出信号确保锁被释放 trap ‘release_lock; log “WARN” “脚本被中断。”; exit 1’ INT TERM main这个脚本体现了多个重要实践安全设置set -euo pipefail。只读变量使用readonly防止意外修改配置。全面的日志所有操作都有日志并同时输出到屏幕和文件。锁机制防止脚本并发执行导致数据错乱。信号捕获使用trap确保即使被中断锁文件也能被清理。详细的错误处理每一步都检查是否成功失败则调用die函数优雅退出。资源清理备份后自动清理旧数据。你可以通过./robust_backup.sh来执行它它会自动处理所有细节。这个脚本的框架可以很容易地适配到其他备份或定时任务场景。