Introduction

A shell wrapper often needs to forward every argument it receives to another command. That sounds simple, but Bash has several similar-looking expansions, and only one of them is correct in most real scripts.

The safe default is "$@". It preserves argument boundaries exactly, including spaces, quotes that have already been parsed by the shell, and empty arguments. Most propagation bugs come from using $@, $*, or an unquoted variable instead.

Why "$@" Is The Right Tool

Bash exposes positional parameters as $1, $2, and so on. For "all arguments," the two special forms people compare are $@ and $*.

The important rule is what happens when they are quoted:

• '"$@" expands to separate arguments'
• '"$*" expands to one single string'

That difference is why wrappers almost always want "$@".

1#!/usr/bin/env bash
2
3echo "count: $#"
4printf 'arg: [%s]\n' "$@"

If the script is called like this:

./wrapper.sh alpha "two words" ""

then "$@" preserves all three arguments exactly, including the empty one.

Forward Arguments To Another Command

The canonical wrapper pattern is:

1#!/usr/bin/env bash
2set -euo pipefail
3
4exec some_command "$@"

Using exec is optional, but it is common when the wrapper's only job is to hand off control to another command. It replaces the shell process with the target command instead of starting an extra child process.

If you need to add fixed options before forwarding the user-provided ones, keep the fixed options separate and still forward the original arguments with "$@":

1#!/usr/bin/env bash
2set -euo pipefail
3
4rsync -av --progress "$@"

This is a common pattern for small command wrappers that enforce defaults without destroying flexibility.

When You Need To Inspect Or Modify Arguments

Sometimes you want to check the first argument, strip an option, or add a flag. Bash makes this easy as long as you continue to preserve argument boundaries.

1#!/usr/bin/env bash
2set -euo pipefail
3
4verbose=false
5if [[ "${1-}" == "--verbose" ]]; then
6  verbose=true
7  shift
8fi
9
10if $verbose; then
11  echo "running with args: $*"
12fi
13
14python3 tool.py "$@"

Here shift removes the first positional parameter, and "$@" forwards the remaining ones correctly. Notice that the debug message uses $* only for display. That is fine because it is being printed, not used as command input.

Arrays Are Better Than Building Strings

If you need to construct a command dynamically, do it with an array rather than string concatenation:

1#!/usr/bin/env bash
2set -euo pipefail
3
4cmd=(python3 tool.py --mode fast)
5cmd+=("$@")
6
7"${cmd[@]}"

This is the safe Bash way to build commands. Concatenating a string such as cmd="python3 tool.py $*" and then executing it later invites quoting bugs and sometimes command-injection bugs.

Common Pitfalls

• Using $@ without quotes, which lets the shell split and glob arguments again.
• Using "$*", which collapses all arguments into one string.
• Printing debug output with one expansion and assuming it behaves the same way when used as a command.
• Building commands with string concatenation instead of arrays.
• Forgetting that shift changes the positional parameters seen by the rest of the script.

Summary

• Use "$@" when you want to forward all original arguments safely.
• '"$@" preserves each argument as a separate value.'
• '"$*" is usually wrong for propagation because it becomes one string.'
• Use arrays when you need to build a command dynamically.
• Treat argument forwarding as a quoting problem first, not a syntax shortcut.