1. 从“脚本小子”到“脚本工匠”的必经之路干了这么多年运维和自动化我经手过的 Shell 脚本没有一千也有八百了。从最初几行的“一次性”脚本到后来动辄几百上千行的复杂自动化流程我踩过最大的一个坑就是脚本的“可维护性”。你有没有过这种经历三个月前写的脚本今天需要加个新功能打开一看满屏都是重复的代码块、硬编码的路径、神秘的魔法数字还有那些早已忘记用途的临时变量。改起来如履薄冰生怕牵一发而动全身。这就是为什么我强烈建议无论你是刚接触 Shell 的开发者还是经验丰富的系统管理员都应该尽早建立自己的“实用函数库”。这不仅仅是代码复用那么简单它关乎效率、可靠性和职业素养。一个精心设计的函数模块就像工具箱里一套趁手的、标准化的扳手和螺丝刀能让你在面对任何“拧螺丝”的任务时都从容不迫。今天要分享的就是我多年积累下来的 Shell 脚本实用函数模块的第一部分。这些函数不是什么高深莫测的黑科技而是那些在几乎每个脚本里都会反复出现的、最基础却又最关键的“脏活累活”。比如如何优雅地输出带颜色的日志如何安全地检查命令执行是否成功如何处理用户输入和参数把这些琐碎但重要的事情封装起来你的脚本主体逻辑会变得异常清晰和健壮。2. 基石函数让脚本输出“会说话”脚本是沉默的但好的脚本应该会“说话”。这里的“说话”指的是清晰、分级、可追溯的日志输出。一个只有成功或失败两种状态的脚本是粗鲁的我们需要它告诉我们它正在做什么做到了哪一步遇到了什么问题以及问题的严重程度。2.1 日志分级与彩色输出直接使用echo打印信息是最原始的做法。我们需要一个更结构化的方式。首先定义日志级别#!/bin/bash # 定义日志级别常量 readonly LOG_LEVEL_DEBUG0 readonly LOG_LEVEL_INFO1 readonly LOG_LEVEL_WARN2 readonly LOG_LEVEL_ERROR3 # 设置当前脚本的默认日志级别 CURRENT_LOG_LEVEL$LOG_LEVEL_INFO接下来是核心的日志打印函数。这里的关键技巧是使用tput命令这是最便携的终端颜色控制方式比硬编码 ANSI 转义序列更可靠。输出到标准错误 (stderr)将日志信息与脚本的正常输出通常到 stdout分离便于重定向和过滤。添加时间戳和调用者信息这对于调试和追踪问题来源至关重要。# 基础日志函数 _log() { local level$1 local level_str$2 local color_code$3 shift 3 local message$* local timestamp$(date %Y-%m-%d %H:%M:%S) # 获取调用该日志函数的脚本文件名和行号非常有用 local caller_info$(caller 0) local caller_line$(echo $caller_info | awk {print $1}) local caller_file$(basename $(echo $caller_info | awk {print $2})) # 判断当前日志级别是否允许打印 if [[ $level -ge $CURRENT_LOG_LEVEL ]]; then # 使用 tput 设置颜色并在结束后重置 if [[ -t 2 ]]; then # 检查 stderr 是否连接到终端 2 echo -e $(tput setaf $color_code)[$timestamp] [$level_str] ($caller_file:$caller_line) $message$(tput sgr0) else # 非终端环境如 cron job、管道不输出颜色代码 2 echo [$timestamp] [$level_str] ($caller_file:$caller_line) $message fi fi } # 封装各级别日志函数 log_debug() { _log $LOG_LEVEL_DEBUG DEBUG 6 $; } # 青色 log_info() { _log $LOG_LEVEL_INFO INFO 2 $; } # 绿色 log_warn() { _log $LOG_LEVEL_WARN WARN 3 $; } # 黄色 log_error() { _log $LOG_LEVEL_ERROR ERROR 1 $; } # 红色使用示例与心得log_info 开始执行数据备份流程... log_debug 源目录: $SOURCE_DIR, 目标目录: $TARGET_DIR # 只有日志级别为 DEBUG 时才打印 cp -r $SOURCE_DIR $TARGET_DIR if [[ $? -eq 0 ]]; then log_info 数据复制成功。 else log_error 数据复制失败 # 红色高亮非常醒目 fi注意tput setaf后面的数字代表颜色索引0-7是基础色具体映射可能因终端而异上述6/2/3/1是较通用的搭配。-t 2检查确保了在日志被重定向到文件时不会写入控制字符避免文件内容混乱。caller 0这个技巧能自动捕获调用位置在排查复杂脚本链的问题时能帮你快速定位到出错的函数。2.2 命令执行检查与错误处理Shell 脚本中命令执行失败是常态。但很多脚本只是简单地和||连接错误处理非常脆弱。我们需要一个统一的、强制的错误处理机制。初级方案run_cmd函数这个函数执行命令并在失败时记录错误日志并退出脚本。# 执行命令失败则退出 run_cmd() { local cmd$* log_info 执行命令: $cmd eval $cmd local ret$? if [[ $ret -ne 0 ]]; then log_error 命令执行失败 (退出码: $ret): $cmd exit $ret # 根据实际情况你可能想返回而非退出 fi return $ret }使用run_cmd cp -f critical_file /backup/。这确保了关键步骤失败时脚本会立即停止避免后续操作在错误状态下进行。进阶方案check_cmd与错误陷阱有时我们不想一失败就退出而是想收集错误最后统一处理。这时可以结合trap使用。ERROR_OCCURREDfalse ERROR_MESSAGES() # 执行命令失败则记录错误但不退出 check_cmd() { local cmd$* log_debug 检查命令: $cmd eval $cmd local ret$? if [[ $ret -ne 0 ]]; then log_error 命令执行失败 (退出码: $ret): $cmd ERROR_OCCURREDtrue ERROR_MESSAGES(命令失败: $cmd (退出码: $ret)) fi return $ret # 仍然返回退出码供调用者判断 } # 在脚本末尾或某个清理点调用 handle_errors() { if [[ $ERROR_OCCURRED true ]]; then log_error 脚本执行过程中发生以下错误 for msg in ${ERROR_MESSAGES[]}; do log_error - $msg done # 可以选择退出也可以进行一些清理操作后退出 exit 1 else log_info 所有检查通过。 fi }实操心得eval的使用需要谨慎因为它会执行变量扩展和命令替换。确保传入run_cmd或check_cmd的命令字符串是你完全信任的或者来自脚本内部的硬编码。对于包含用户输入的部分应进行严格的过滤和转义。在复杂的生产脚本中我更多使用check_cmd模式因为它提供了更大的灵活性允许实现“原子性”操作——要么全部成功要么在清理后失败。3. 输入处理函数与用户和参数安全打交道脚本的另一个脆弱点是输入。位置参数$1, $2...直接使用read命令裸奔都是潜在的 Bug 来源。3.1 参数解析与验证我们来实现一个简单的、支持长短选项的参数解析函数。它不追求getopts或getopt的全面性但胜在清晰易懂能满足大部分日常需求。# 声明一个关联数组来存储解析后的参数 declare -A ARGS # 简易参数解析器 # 用法: parse_args $ # 支持格式: -f value, --flag value, --flagvalue parse_args() { local key local value local is_valuefalse for arg in $; do if [[ $is_value true ]]; then value$arg ARGS[$key]$value is_valuefalse key elif [[ $arg ~ ^-{1,2}([a-zA-Z0-9_-])$ ]]; then # 匹配 -f 或 --flag key${BASH_REMATCH[1]} # 检查下一个参数是否是值而不是另一个选项 is_valuetrue elif [[ $arg ~ ^-{1,2}([a-zA-Z0-9_-])(.*)$ ]]; then # 匹配 --flagvalue key${BASH_REMATCH[1]} value${BASH_REMATCH[2]} ARGS[$key]$value key is_valuefalse else # 非选项参数可以放入一个数组这里简单处理为“命令” ARGS[_command]$arg fi done # 处理最后一个参数是独立值的情况 if [[ -n $key $is_value true ]]; then log_warn 参数 --$key 后面缺少值将被忽略。 unset ARGS[$key] fi } # 获取参数值可提供默认值 get_arg() { local key$1 local default_value${2:-} # 第二个参数是默认值 echo ${ARGS[$key]:-$default_value} }使用示例#!/bin/bash # 引入上面的函数 parse_args $ config_file$(get_arg config /etc/default/myapp) verbose$(get_arg v ) force$(get_arg force false) log_info 使用的配置文件: $config_file if [[ -n $verbose ]]; then CURRENT_LOG_LEVEL$LOG_LEVEL_DEBUG fi3.2 安全的用户输入与交互对于需要交互式输入的脚本read命令是标配但直接使用有风险比如输入中包含空格、特殊符号等。下面这个函数提供了带提示、超时和默认值的安全读取。# 安全读取用户输入 safe_read() { local prompt$1 local default_value${2:-} local timeout${3:-0} # 超时时间0表示无限等待 local var_name$4 # 要赋值给的变量名 local user_input # 构造提示信息 local full_prompt$prompt if [[ -n $default_value ]]; then full_prompt [默认: $default_value] fi full_prompt: if [[ $timeout -gt 0 ]]; then # 带超时的读取 if read -t $timeout -r -p $full_prompt user_input; then : # 读取成功 else log_warn 输入超时将使用默认值。 user_input fi else # 无限等待 read -r -p $full_prompt user_input fi # 处理输入如果用户直接回车则使用默认值 if [[ -z $user_input -n $default_value ]]; then user_input$default_value log_info 已使用默认值: $default_value fi # 将结果赋值给指定变量 if [[ -n $var_name ]]; then printf -v $var_name %s $user_input else echo $user_input fi }使用示例与避坑指南# 询问备份路径默认当前目录10秒超时 backup_dir if safe_read 请输入备份目录 $(pwd) 10 backup_dir; then # 这里可以验证 backup_dir 是否合法 if [[ ! -d $backup_dir ]]; then log_error 目录不存在: $backup_dir exit 1 fi else log_error 未能获取有效的备份目录。 exit 1 fi log_info 备份目录设置为: $backup_dir重要提示read -r中的-r选项至关重要它禁止反斜杠转义。如果没有它用户输入path\to\file会被错误解释。printf -v用于将字符串安全地赋值给一个变量这是一种比直接eval更安全的做法。对于生产脚本在得到用户输入后必须进行验证比如检查路径是否存在、是否具有写权限、输入是否包含非法字符等这是防御脚本注入和误操作的关键。4. 文件与路径操作函数处理文件和路径是 Shell 脚本的日常。Bash 本身提供了很多功能但组合起来使用时常需要小心翼翼。4.1 绝对路径规范化与目录确保realpath或readlink -f命令可以获取绝对路径但并非所有系统都默认安装。我们可以实现一个兼容性更好的版本。# 获取文件的绝对路径简易兼容版 get_abs_path() { local path$1 # 如果路径是相对路径则拼接当前工作目录 if [[ ! $path ~ ^/ ]]; then path$(pwd)/$path fi # 简化路径中的 . 和 .. # 这里使用了一个技巧利用 cd 和 pwd 命令 local abs_path if abs_path$(cd $(dirname $path) pwd); then echo $abs_path/$(basename $path) else log_error 无法解析路径: $path return 1 fi } # 确保目录存在如果不存在则创建 ensure_dir() { local dir$1 local mode${2:-0755} # 默认权限 755 if [[ ! -d $dir ]]; then log_info 创建目录: $dir (权限: $mode) mkdir -p -m $mode $dir if [[ $? -ne 0 ]]; then log_error 创建目录失败: $dir return 1 fi else log_debug 目录已存在: $dir fi }4.2 安全的文件操作备份、写入直接覆盖文件是危险的。一个好的习惯是在修改重要文件前先备份。# 安全备份文件 backup_file() { local file$1 local suffix${2:-.bak.$(date %Y%m%d_%H%M%S)} local backup_file${file}${suffix} if [[ ! -f $file ]]; then log_warn 文件不存在无需备份: $file return 0 fi cp -p $file $backup_file # -p 保留属性 local ret$? if [[ $ret -eq 0 ]]; then log_info 已备份文件: $file - $backup_file else log_error 文件备份失败: $file fi return $ret } # 原子性写入文件避免写入过程中文件损坏 atomic_write() { local content$1 local target_file$2 local tmp_file${target_file}.tmp.$$ # 使用 PID 确保临时文件唯一 # 将内容写入临时文件 echo $content $tmp_file local ret$? if [[ $ret -ne 0 ]]; then log_error 写入临时文件失败: $tmp_file rm -f $tmp_file return $ret fi # 将临时文件原子性地移动到目标位置 mv -f $tmp_file $target_file ret$? if [[ $ret -eq 0 ]]; then log_debug 文件已原子写入: $target_file else log_error 移动临时文件到目标失败: $target_file rm -f $tmp_file fi return $ret }使用场景当你需要动态生成配置文件时atomic_write可以确保即使在写入过程中脚本被中断目标文件也只会处于完全旧或完全新的状态而不会是一个半截的损坏文件。cp -p在备份时保留原文件的权限、所有者和时间戳这在恢复时非常重要。5. 系统与环境检查函数脚本的可移植性和健壮性很大程度上取决于它对运行环境的检查。假设所有系统都一样是脚本失败的主要原因之一。5.1 依赖命令检查在脚本开始执行实质性工作前检查所有必需的命令是否可用。# 检查命令是否存在 check_command() { local cmd$1 # type 命令比 which 或 command -v 更符合 POSIX 标准且在 Bash 中可靠 if ! type $cmd /dev/null; then log_error 必需的命令未找到: $cmd return 1 else log_debug 命令可用: $cmd return 0 fi } # 批量检查多个命令 check_commands() { local missing_commands() for cmd in $; do if ! check_command $cmd; then missing_commands($cmd) fi done if [[ ${#missing_commands[]} -gt 0 ]]; then log_error 以下必需命令缺失请安装: ${missing_commands[*]} return 1 fi log_info 所有必需命令检查通过。 return 0 }5.2 运行环境与权限检查检查脚本是否以合适的用户、在合适的目录下运行。# 检查是否以 root 用户运行 check_root() { if [[ $EUID -ne 0 ]]; then log_error 此脚本需要 root 权限才能运行。 return 1 fi return 0 } # 检查当前工作目录是否在特定路径下防止在错误目录执行 check_working_dir() { local expected_dir$1 local current_dir$(pwd) # 使用模式匹配允许 expected_dir 是当前目录的子串或完全匹配 if [[ $current_dir ! *$expected_dir* ]]; then log_error 当前目录 $current_dir 不符合预期。请在 $expected_dir 或其子目录下运行。 return 1 fi return 0 } # 检查磁盘空间单位MB check_disk_space() { local path$1 local required_mb$2 local available_mb # df -BM 输出以 MB 为单位的块提取可用空间 if available_mb$(df -BM --outputavail $path 2/dev/null | tail -1 | tr -d M); then if [[ $available_mb -lt $required_mb ]]; then log_error 路径 $path 磁盘空间不足。需要 ${required_mb}MB仅剩 ${available_mb}MB。 return 1 else log_debug 磁盘空间充足: 路径 $path, 可用 ${available_mb}MB, 需要 ${required_mb}MB。 return 0 fi else log_error 无法检查路径 $path 的磁盘空间。 return 1 fi }综合使用示例#!/bin/bash # 引入所有函数模块 # 1. 设置日志级别 CURRENT_LOG_LEVEL$LOG_LEVEL_INFO # 2. 检查依赖 log_info 开始环境预检... check_commands awk sed tar gzip ssh || exit 1 # 3. 检查权限如果不是root尝试提示 if ! check_root; then log_warn 部分操作可能需要 root 权限将继续以普通用户执行。 fi # 4. 检查工作目录 check_working_dir /opt/myapp || exit 1 # 5. 检查备份目录磁盘空间 BACKUP_DIR/backup REQUIRED_SPACE_MB1024 # 1GB check_disk_space $BACKUP_DIR $REQUIRED_SPACE_MB || { log_error 磁盘空间检查失败退出。 exit 1 } log_info 环境预检全部通过开始主流程...经验之谈这些检查函数应该放在脚本的最开始越早失败越好Fail Fast。这避免了脚本执行到一半才发现环境不满足导致部分操作已执行、系统处于中间状态的尴尬局面。check_commands函数给出的错误信息要明确告诉用户需要安装什么包例如“请通过yum install tar gzip安装相关工具”。df命令的--output选项是 GNU coreutils 的特性如果你的脚本需要运行在 BSD 系统如 macOS上需要使用df -m /path | awk NR2 {print $4}这种更兼容的写法这就是为什么封装函数时需要考虑跨平台性。6. 字符串与数组操作辅助函数Bash 的字符串和数组操作语法强大但略显晦涩封装成函数能极大提升代码可读性。6.1 字符串修剪与空值处理处理用户输入或配置文件时去除多余的空格、判断空值是最常见的需求。# 修剪字符串首尾的空白字符兼容旧版Bash不使用 -v 赋值 trim() { local str$* # 使用 sed 删除开头和结尾的空白 str$(echo $str | sed -e s/^[[:space:]]*// -e s/[[:space:]]*$//) echo $str } # 判断字符串是否为空或仅包含空白 is_empty_or_whitespace() { local str$* # 修剪后判断长度 local trimmed$(trim $str) [[ -z $trimmed ]] } # 提供默认值如果第一个参数为空则返回第二个参数 default_value() { local value$1 local default$2 if is_empty_or_whitespace $value; then echo $default else echo $value fi }6.2 数组操作辅助Bash 数组很实用但一些常见操作如连接、包含判断没有内置函数。# 将数组合并为字符串用指定分隔符连接 join_by() { local delimiter$1 shift local first$1 shift printf %s $first ${/#/$delimiter} # 这是一个巧妙的用法 } # 判断元素是否在数组中 array_contains() { local seeking$1 shift local element for element in $; do if [[ $element $seeking ]]; then return 0 # 找到返回成功 fi done return 1 # 未找到返回失败 }使用示例# 处理配置项 config_line database_host 127.0.0.1 clean_line$(trim $config_line) # clean_line 现在是 database_host 127.0.0.1 # 连接数组 files(app.log error.log access.log) log_files_str$(join_by , ${files[]}) # log_files_str 是 app.log, error.log, access.log # 检查有效性 valid_modes(start stop restart status) user_mode$(get_arg mode) if ! array_contains $user_mode ${valid_modes[]}; then log_error 无效的模式: $user_mode。有效模式为: $(join_by , ${valid_modes[]}) exit 1 fi7. 模块的集成与使用建议上面这些函数单独看每一个都不复杂但组合在一起就能为你的 Shell 脚本开发提供一个坚实的“地基”。我的建议是创建一个名为shell_utils.sh或common_functions.sh的文件把这些函数都放进去。如何集成在你的主脚本开头通过source命令引入#!/bin/bash set -euo pipefail # 这是一个好习惯遇到错误退出未定义变量报错管道中任意命令失败则整个管道失败 # 引入函数库 SCRIPT_DIR$(cd $(dirname ${BASH_SOURCE[0]}) pwd) source $SCRIPT_DIR/shell_utils.sh # 现在可以愉快地使用所有函数了 log_info 脚本启动... parse_args $ check_commands jq curl ...版本管理与迭代这个函数库不是一成不变的。随着你写的脚本越来越多会遇到新的通用需求比如发送 HTTP 请求、解析 JSON、处理日期计算等。你应该持续地将这些经过验证的、通用的代码提炼成函数补充到你的库中。同时也要定期回顾优化旧函数比如提高兼容性、修复边界情况下的 Bug。一个完整的脚本骨架示例#!/bin/bash set -euo pipefail # --- 引入函数库 --- UTILS_DIR$(dirname $0)/../lib source $UTILS_DIR/shell_utils.sh # --- 脚本元信息与配置 --- SCRIPT_NAME$(basename $0) VERSION1.0.0 DEFAULT_CONFIG/etc/${SCRIPT_NAME%.*}.conf # --- 主函数 --- main() { log_info $SCRIPT_NAME (v$VERSION) 开始执行 # 1. 解析参数 parse_args $ local config_file$(get_arg config $DEFAULT_CONFIG) local verbose$(get_arg verbose) if [[ -n $verbose ]]; then CURRENT_LOG_LEVEL$LOG_LEVEL_DEBUG log_debug 启用详细日志模式。 fi # 2. 加载配置假设是一个简单的 keyvalue 文件 log_info 加载配置文件: $config_file if [[ -f $config_file ]]; then source $config_file || log_warn 配置文件存在但加载失败。 else log_warn 配置文件不存在将使用内置默认值。 fi # 3. 环境检查 check_commands rsync find xargs || exit 1 ensure_dir $BACKUP_DIR 0750 check_disk_space $BACKUP_DIR 500 # 至少500MB # 4. 核心业务逻辑 perform_backup log_info $SCRIPT_NAME 执行完成 } # --- 核心业务函数 --- perform_backup() { local timestamp$(date %Y%m%d_%H%M%S) local backup_file$BACKUP_DIR/backup_$timestamp.tar.gz log_info 开始备份到: $backup_file # 使用 run_cmd 确保关键步骤失败则整体失败 run_cmd tar -czf $backup_file -C $SOURCE_DIR . log_info 备份文件创建成功。 # 清理旧备份保留最近7天 log_info 清理7天前的旧备份... find $BACKUP_DIR -name backup_*.tar.gz -mtime 7 -delete log_info 清理完成。 } # --- 脚本入口 --- # 只有直接执行此脚本时才调用 main if [[ ${BASH_SOURCE[0]} ${0} ]]; then main $ fi看到这里你可能觉得这些函数模块增加了脚本的“样板代码”。但请相信我在任何一个需要长期维护、多人协作或处理重要任务的脚本项目中前期在基础设施上投入的这一点点时间会在日后为你节省数倍于它的调试和维护时间。它让你的脚本从“能跑就行”的草稿变成了清晰、健壮、可信赖的工程化作品。这才是从“脚本小子”迈向“脚本工匠”的标志。