Introduction

Bash functions receive parameters the same way shell scripts do: by position. That sounds simple, but the details around quoting, $@, shift, local variables, and return values matter a lot if you want reliable shell code. Most bugs in Bash functions are not caused by the function syntax itself. They come from argument handling mistakes.

Positional Parameters Work Just Like Script Arguments

Inside a Bash function, $1, $2, and so on refer to the arguments passed to that function call.

1greet() {
2  echo "Hello, $1. Today is $2."
3}
4
5greet "Alice" "Monday"

That prints a greeting using the first and second positional parameters. The special variable $# tells you how many arguments were passed.

1show_count() {
2  echo "Argument count: $#"
3}
4
5show_count one two three

This is the starting point for almost all Bash function parameter handling.

Use "$@" for All Arguments Safely

If a function needs to forward or iterate over all arguments, use "$@", not bare $@ and almost never "$*".

1list_args() {
2  for arg in "$@"; do
3    printf 'arg: [%s]\n' "$arg"
4  done
5}
6
7list_args "file one.txt" "file two.txt"

"$@" preserves argument boundaries correctly, including spaces. That is the safe default for shell functions.

By contrast, "$*" joins all arguments into one string, which is rarely what you want when forwarding parameters.

Use shift When Parsing Options

Functions that process a variable number of arguments often consume them step by step with shift.

1parse_flags() {
2  local verbose=0
3
4  while (($# > 0)); do
5    case "$1" in
6      --verbose)
7        verbose=1
8        shift
9        ;;
10      --)
11        shift
12        break
13        ;;
14      *)
15        break
16        ;;
17    esac
18  done
19
20  echo "verbose=$verbose"
21  echo "remaining args: $*"
22}
23
24parse_flags --verbose -- file1 file2

This pattern is common in real scripts because it separates option parsing from remaining positional arguments.

Use Local Variables to Avoid Polluting Global State

Bash variables are global by default inside functions unless you mark them local.

1join_name() {
2  local first="$1"
3  local last="$2"
4  echo "$first $last"
5}

Using local is a small discipline that prevents a lot of accidental interference between functions in larger shell scripts.

Bash Functions Return Status Codes, Not Arbitrary Values

A Bash function can return, but that return is only an exit status from 0 to 255. It is not how you return strings or large numbers.

1is_even() {
2  local n="$1"
3  (( n % 2 == 0 ))
4}
5
6if is_even 4; then
7  echo "even"
8fi

If you want the function to produce a data value, print it and capture the output.

1add() {
2  local a="$1"
3  local b="$2"
4  echo $((a + b))
5}
6
7result="$(add 3 5)"
8echo "$result"

That distinction between status and output is fundamental in shell programming.

Validate Parameters Early

Because Bash is loosely typed, good functions validate what they need up front.

1require_two_args() {
2  if (($# != 2)); then
3    echo "usage: require_two_args first second" >&2
4    return 1
5  fi
6
7  echo "first=$1 second=$2"
8}

Failing early makes shell scripts much easier to debug, especially once they start calling other commands and functions transitively.

Common Pitfalls

• Forgetting to quote "$@" and breaking arguments that contain spaces.
• Using return when the function really needs to output a value.
• Omitting local and accidentally overwriting global shell variables.
• Confusing "$*" with "$@" when forwarding arguments.
• Parsing options manually without shift, leading to brittle argument handling.

Summary

• Bash function parameters are positional and accessed with $1, $2, and so on.
• Use "$@" to handle all arguments safely.
• Use shift for option parsing and variable-length argument processing.
• Use local inside functions to avoid leaking state.
• Remember that Bash functions return status codes, while data values are usually emitted via stdout.