交互式环境正常的Bash sourced函数Getopts，测试脚本中失效？

Let’s dig into why your custom prunner works flawlessly in an interactive Bash shell but fails when run in a test script—this kind of inconsistency almost always ties to differences in how Bash behaves across interactive/non-interactive modes, or how your function handles argument parsing and job control.

Common Causes & Fixes #

1. Wildcard (Globbing) Expansion Issues #

In interactive shells, *.out gets expanded to the actual list of matching files before it’s passed to prunner. But in test scripts, this might not happen as expected:

• If your script has set -f (glob disabling) enabled accidentally, *.out will be treated as a literal string instead of expanding to files. Add set +f at the top of your test script or inside prunner to re-enable globbing.
• Double-check that your function uses $@ to capture positional arguments (the expanded files) instead of $*—$@ preserves individual file names correctly, even if they have spaces.

2. Broken Command Parsing for the -c Flag #

When you pass "gzip -fk" as the command, your function needs to split this into the command (gzip) and its argument (-fk) instead of treating the whole string as a single executable. If you’re using eval or storing the command as a single string, word splitting rules in non-interactive shells can break this.

Fix this by storing the command in an array instead of a string—arrays avoid messy word splitting issues:

prunner() {
    local cmd=()
    local job_count=4  # Default concurrent jobs
    # Parse flags
    while getopts "c:t:" opt; do
        case "$opt" in
            c) cmd=($OPTARG) ;;  # Split command into array elements
            t) job_count="$OPTARG" ;;
            *) echo "Invalid option: -$opt" >&2; return 1 ;;
        esac
    done
    shift $((OPTIND - 1))  # Remove parsed flags from arguments

    # Run commands with concurrency control
    local running_jobs=0
    for file in "$@"; do
        # Execute the command array with the current file
        "${cmd[@]}" "$file" &
        ((running_jobs++))

        # Wait for a job to finish if we hit the concurrency limit
        if (( running_jobs >= job_count )); then
            wait -n
            ((running_jobs--))
        fi
    done
    # Wait for any remaining jobs to finish
    wait
}

3. Missing Interactive Shell Configurations #

Interactive shells load your ~/.bashrc or ~/.bash_profile, which might define aliases, environment variables, or function dependencies that prunner relies on. Non-interactive test scripts don’t load these by default.

• If prunner depends on something from your shell config, add source ~/.bashrc at the top of your test script (but be careful—this can introduce unintended side effects). Better yet, rewrite prunner to be self-contained, no external dependencies.
• Verify that gzip is in the PATH used by your test script. Run which gzip in both your interactive shell and test script to compare—non-interactive shells often have a more restricted PATH.

4. Job Control Disabled in Non-Interactive Shells #

Bash turns off job control by default in non-interactive mode, which can mess with how background processes and the wait command work in prunner.

• Add set -m at the top of your test script or inside the prunner function to enable job control, which lets you manage background jobs properly.

Debugging Steps to Narrow It Down #

• Add debug prints to your prunner function to see what’s happening:

  echo "Received command: ${cmd[*]}"
  echo "Files to process: $@"
  echo "Current running jobs: $running_jobs"
  

• Run your test script with bash -x test_script.sh—this enables debug tracing, showing every command executed. You’ll spot exactly where parsing or execution goes off the rails.

内容的提问来源于stack exchange，提问作者MrDrMcCoy