掌握位置参数：Bash脚本参数完全指南

当Bash脚本能够接受参数，而不是要求你手动编辑文件中的变量时，它们会变得更有用。备份脚本应该接受源目录。部署脚本应该接受环境名称。清理脚本应该接受一个或多个路径。这些值以位置参数的形式传入：$1、$2、$3，依此类推。

棘手的部分不是读取$1。棘手的部分是处理缺失的参数、包含空格的参数、可选标志，以及当你的脚本从“仅供自己使用”发展到别人会在凌晨2点运行的时候。

---

位置参数的构成

位置参数是由Shell定义的特殊变量，对应于脚本名称之后命令行上提供的单词。它们从1开始顺序编号。

参数	描述	示例值（运行 ./script.sh file1 dir/ 时）
$0	脚本本身（或函数）的名称。	./script.sh
$1	传递给脚本的第一个参数。	file1
$2	传递给脚本的第二个参数。	dir/
$N	第N个参数（其中N > 0）。
${10}	超过9的参数必须用花括号括起来。

访问第9个之后的参数

虽然参数1到9可以直接通过$1到$9访问，但访问第十个及之后的参数需要用花括号将数字括起来，以避免与环境变量或字符串操作产生歧义（例如，使用${10}而不是$10）。

---

脚本编写中必不可少的特殊参数

除了数字参数之外，Bash还提供了几个与整个参数集相关的关键特殊变量。这些变量对于验证和迭代是不可或缺的。

使用 $# 统计参数个数

特殊变量$#保存了传递给脚本的命令行参数总数（不包括$0）。这可能是实现输入验证最重要的变量。

#!/bin/bash

if [ "$#" -eq 0 ]; then
    echo "错误：未提供参数。"
    echo "用法：$0 <输入文件>"
    exit 1
fi

echo "你提供了 $# 个参数。"

所有参数：$@ 和 $*

变量$@和$*都表示完整的参数列表，但它们的行为不同——尤其是在被引号括起来时。

$*（单个字符串）

当用双引号括起来时（"$*"），整个位置参数列表被视为单个参数，由IFS（内部字段分隔符）变量的第一个字符（通常是空格）分隔。

• 如果输入参数是：arg1 arg2 arg3
• "$*" 展开为："arg1 arg2 arg3"（一个单一元素）

$@（单独的字符串 - 推荐）

当用双引号括起来时（"$@"），每个位置参数都被视为一个单独的、被引号括起来的参数。这是标准且推荐的方法，用于遍历参数，因为它能正确地保留包含空格的参数。

• 如果输入参数是：arg1 "arg with space" arg3
• "$@" 展开为："arg1" "arg with space" "arg3"（三个不同的元素）

为什么引号很重要：一个演示

考虑一个使用参数 ./test.sh 'hello world' file.txt 运行的脚本：

#!/bin/bash

# 未加引号的 $* 会在空格处分割，通常是错误的。
echo "-- 使用未加引号的 $* 进行循环 --"
for item in $*; do
    echo "项目：$item"
done

# 加引号的 "$@" 保留每个原始参数。
echo "-- 使用加引号的 $@ 进行循环 --"
for item in "$@"; do
    echo "项目：$item"
done

使用 ./test.sh 'hello world' file.txt，未加引号的循环将 hello 和 world 打印为单独的项目。而 "$@" 循环将 hello world 保持为一个参数。这种差异就是为什么有经验的Shell用户几乎会自动使用 "$@" 的原因。

---

参数处理的实用技巧

1. 基本参数检索脚本

这个简单的脚本演示了如何访问特定参数以及如何使用 $0 提供有用的反馈。

deploy_service.sh：

#!/bin/bash
# 用法：deploy_service.sh <服务名称> <环境>

SERVICE_NAME="$1"
ENVIRONMENT="$2"

# 验证检查（至少两个参数）
if [ "$#" -lt 2 ]; then
    echo "用法：$0 <服务名称> <环境>"
    exit 1
fi

echo "开始部署服务：$SERVICE_NAME"
echo "目标环境：$ENVIRONMENT"

# 使用验证后的参数运行命令
ssh admin@server-"$ENVIRONMENT" "/path/to/start $SERVICE_NAME"

2. 健壮的输入验证

好的脚本在继续执行之前总是会验证输入。这包括检查数量（$#），并且通常检查参数的内容（例如，检查参数是否为数字或有效的文件路径）。

#!/bin/bash

# 1. 检查参数数量（必须恰好为3）
if [ "$#" -ne 3 ]; then
    echo "错误：此脚本需要三个参数（源路径、目标路径、用户）。"
    echo "用法：$0 <源路径> <目标路径> <用户>"
    exit 1
fi

SRC_PATH="$1"
DEST_PATH="$2"
USER="$3"

# 2. 检查内容（示例：验证源路径是否存在）
if [ ! -f "$SRC_PATH" ]; then
    echo "错误：源文件 '$SRC_PATH' 未找到或不是文件。"
    exit 2
fi

# 如果验证通过，继续执行
echo "正在以用户 $USER 身份将 $SRC_PATH 复制到 $DEST_PATH..."

最佳实践提示： 当验证失败时，始终提供一个清晰、简洁的 用法： 语句。这有助于用户快速修复他们的命令调用。

3. 使用 shift 遍历参数

shift 命令是顺序处理参数的绝佳工具，通常用于处理简单标志或在 while 循环中逐个处理参数。

shift 丢弃当前的 $1 参数，将 $2 移动到 $1，$3 移动到 $2，并将 $# 减一。这允许你处理第一个参数，然后循环直到没有剩余参数。

#!/bin/bash

# 处理一个简单的 -v 标志，然后列出剩余文件

VERBOSE=false

if [ "$1" = "-v" ]; then
    VERBOSE=true
    shift  # 丢弃 -v 标志并向上移动参数
fi

if $VERBOSE; then
    echo "已启用详细模式。"
fi

if [ "$#" -eq 0 ]; then
    echo "未指定文件。"
    exit 0
fi

echo "正在处理 $# 个剩余文件："
for file in "$@"; do
    if $VERBOSE; then
        echo "正在检查文件：$file"
    fi
    # ... 此处为处理逻辑
done

注意： shift 适用于简单的解析。对于包含许多标志的复杂脚本，getopts 通常是短选项的更好选择。长选项的处理因平台而异，因此如果你使用外部的 getopt，请仔细测试。

一个更实际的解析器

许多内部脚本以一个可选标志和一个必需值开始。这是一个保持可读性的小模式：

#!/usr/bin/env bash
set -u

dry_run=false
environment=""

usage() {
    echo "用法：$0 [--dry-run] --env <dev|staging|prod> <文件>..." >&2
}

while [ "$#" -gt 0 ]; do
    case "$1" in
        --dry-run)
            dry_run=true
            shift
            ;;
        --env)
            if [ "$#" -lt 2 ]; then
                echo "错误：--env 需要一个值。" >&2
                usage
                exit 2
            fi
            environment="$2"
            shift 2
            ;;
        --help|-h)
            usage
            exit 0
            ;;
        --)
            shift
            break
            ;;
        -*)
            echo "错误：未知选项：$1" >&2
            usage
            exit 2
            ;;
        *)
            break
            ;;
    esac
done

if [ -z "$environment" ]; then
    echo "错误：--env 是必需的。" >&2
    usage
    exit 2
fi

if [ "$#" -eq 0 ]; then
    echo "错误：请至少提供一个文件。" >&2
    usage
    exit 2
fi

for file in "$@"; do
    if [ ! -f "$file" ]; then
        echo "错误：文件未找到：$file" >&2
        exit 3
    fi

    if $dry_run; then
        echo "将上传 $file 到 $environment"
    else
        echo "正在上传 $file 到 $environment"
        # 此处为上传命令
    fi
done

注意这些枯燥的细节。错误信息输出到 stderr。-- 表示“停止解析选项”，这允许某人传递一个以破折号开头的文件名。最后的文件循环使用了 "$@"，因此 release notes.txt 保持为一个文件名。

常见错误

最常见的错误是忘记引号：

cp $1 $2

当任一路径包含空格或Shell通配符时，这就会出错。请使用：

cp -- "$1" "$2"

-- 告诉许多命令选项解析已完成，这有助于处理以 - 开头的路径。

另一个常见错误是验证得太晚。如果你的脚本期望两个参数，请在执行任何破坏性操作之前进行检查：

if [ "$#" -ne 2 ]; then
    echo "用法：$0 <源> <目标>" >&2
    exit 2
fi

当有助于调用者时，使用不同的退出码。用法错误可能是 2；文件未找到可能是 3；失败的外部命令可以保留其自身的状态。你不需要一个庞大的退出码分类法，但在错误的调用后返回 0 会使自动化更难信任。

函数也有位置参数

在Bash函数内部，$1 和 $2 指的是函数的参数，而不是脚本的原始参数。

log_copy() {
    local src="$1"
    local dest="$2"

    echo "正在将 $src 复制到 $dest"
    cp -- "$src" "$dest"
}

log_copy "$1" "$2"

这很有用，但如果你期望函数内部的 $1 指的是脚本级别的第一个参数，它可能会让你感到惊讶。请显式传递值。这使函数更容易测试和重用。

将参数转发给另一个命令

许多包装脚本的存在只是为了在调用另一个命令之前添加一些设置。在这种情况下，"$@" 是保持包装脚本诚实的关键。

#!/usr/bin/env bash
set -e

export APP_ENV=staging
exec /usr/local/bin/myapp "$@"

如果有人运行：

./run-staging.sh --config "config with spaces.yml" --verbose

被包装的命令会收到相同的三个参数。如果你使用了 $* 或未加引号的 $@，配置路径可能会被分割成几个单词。

exec 是可选的，但在包装脚本中通常很有用，因为它用目标进程替换了Shell进程。这使得信号在systemd、Docker或进程管理器下的行为更可预测。

没有意外的默认值

有时参数应该是可选的。Bash参数扩展可以提供帮助：

environment="${1:-dev}"

这意味着“如果 $1 已设置且非空，则使用它；否则使用 dev。”这对于友好的本地脚本来说没问题，但对于生产脚本要小心。如果某人忘记了一个参数，静默的默认值可能会部署到错误的环境。

对于有风险的命令，最好使用显式输入：

if [ "$#" -lt 1 ]; then
    echo "用法：$0 <环境>" >&2
    exit 2
fi

默认值最适合在后果很小的情况下使用，例如默认日志级别或输出目录。当参数选择服务器、删除数据或更改部署目标时，使用默认值是有风险的。

位置参数和 set -u

许多Bash脚本使用 set -u，以便未设置的变量会导致错误。这可以捕获拼写错误，但它也会改变缺失位置参数的行为。

#!/usr/bin/env bash
set -u

echo "第一个参数：$1"

在没有参数的情况下运行该脚本，Bash会退出并显示“未绑定变量”错误。这个错误在技术上是正确的，但并不友好。在读取必需参数之前，请验证 $#：

if [ "$#" -lt 1 ]; then
    echo "用法：$0 <输入文件>" >&2
    exit 2
fi

input_file="$1"

对于 set -u 下的可选参数，使用受保护的扩展：

mode="${2:-default}"

这保持了严格模式的有用性，同时不会因为缺失可选值而导致脚本崩溃。

何时位置参数是错误的接口

位置参数对于小型命令来说很棒：

backup.sh /var/www /backup/www.tar.gz

当脚本需要许多值时，它们变得难以阅读：

deploy.sh prod us-east-1 api v2.4.1 true false 30

没有人愿意记住第五个参数的含义。一旦脚本达到这个程度，请使用命名标志或配置文件：

deploy.sh --env prod --region us-east-1 --service api --version v2.4.1 --timeout 30

代码稍长一些，但命令行变得自文档化。对于团队使用的脚本来说，这是一个很好的权衡。

良好的位置参数处理主要是纪律：尽早验证，除非你故意想要分割，否则对每个扩展都加引号，使用 "$@" 转发参数，并将用法信息保持在触发它们的检查附近。这些习惯能让小型脚本经受住真实文件名、真实用户和真实自动化的考验。