---

Master Bash Parameter Expansion: The Ultimate 'Two Fer' Guide

The 'Two Fer' problem in Bash scripting is a classic exercise demonstrating conditional string output. It's solved using Bash's parameter expansion ${1:-you} to provide a default value ('you') for the first positional parameter ($1) if it is null or unset, creating dynamic, user-friendly scripts.

You've just written your first Bash script. It's elegant, it's functional, and it solves a real problem. You share it with a colleague, but a moment later they report back: "It's broken!" The reason? They forgot to provide a command-line argument, and your script crashed ungracefully. This is a frustratingly common hurdle when building command-line tools.

What if there was a simple, built-in Bash feature that could handle missing inputs elegantly, often in a single line of code, making your scripts more robust and user-friendly? There is. This guide will perform a deep dive into that exact feature—parameter expansion—using the foundational 'Two Fer' problem from the exclusive kodikra.com curriculum. By the end, you'll not only solve the problem but also master a core concept for writing professional-grade shell scripts.

---

What Exactly is the 'Two Fer' Problem?

Before we dive into the code, let's understand the challenge. The name 'Two Fer' is a colloquialism for "two for one," a common sales offer. The premise of this coding module is simple and relatable: imagine you're at a bakery with a "two for one" cookie deal. You decide to generously give the extra cookie to someone.

The task is to create a script that generates the correct sentence based on whether you know the recipient's name.

• If you know their name (e.g., "Alice"), the script should output: One for Alice, one for me.
• If you do not know their name, the script should default to using "you": One for you, one for me.

This logic can be summarized in the following examples:

Input Name	Expected Script Output
Alice	One for Alice, one for me.
Bohdan	One for Bohdan, one for me.
(No name provided)	One for you, one for me.
Zaphod	One for Zaphod, one for me.

At its heart, this problem isn't about cookies; it's a test of your ability to handle optional input and provide a sensible default. This is a cornerstone of robust software design, whether you're building a simple script or a complex application.

---

Why This Simple Problem is a Gateway to Advanced Scripting

The 'Two Fer' module might seem trivial, but the concept it teaches—handling default values for parameters—is absolutely critical in the world of shell scripting, DevOps, and system administration. Every robust script needs to anticipate and manage situations where input is missing.

This is where Bash's built-in features shine. Instead of writing clunky if-else blocks to check if an argument was provided, Bash gives us a powerful and concise syntax called Parameter Expansion. Mastering this concept is what separates a novice from an experienced scripter.

The solution revolves around understanding two key components:

1. Positional Parameters: These are special variables ($1, $2, $3, etc.) that hold the arguments passed to your script from the command line. $1 holds the first argument, $2 the second, and so on.
2. Parameter Expansion with Default Values: A specific syntax, ${parameter:-default}, that allows you to substitute a default value if the parameter is unset or null.

By combining these two, we can craft a one-line solution that is both elegant and highly efficient.

---

How to Solve 'Two Fer': A Deep Dive into the Code

The official solution provided in the kodikra learning path is remarkably concise and powerful. Let's look at the code first, and then we will meticulously break down every single component to understand its inner workings.

The One-Line Solution

#!/usr/bin/env bash

# This script prints a "Two Fer" message.
# It takes one optional argument: the name of the recipient.
# If no name is provided, it defaults to "you".

echo "One for ${1:-you}, one for me."

When you run this script from your terminal, you get the desired behavior:

# --- Case 1: Name is provided ---
$ ./two_fer.sh Do-yun
One for Do-yun, one for me.

# --- Case 2: No name is provided ---
$ ./two_fer.sh
One for you, one for me.

This works perfectly. But how does it work? Let's dissect it piece by piece.

Code Walkthrough

1. The Shebang: #!/usr/bin/env bash

Every proper shell script should start with a "shebang" line. This line tells the operating system which interpreter should be used to execute the script's commands. While you might often see #!/bin/bash, using #!/usr/bin/env bash is generally considered superior for portability. It tells the system to find the bash executable in the user's environment path, which is more flexible than hardcoding its location to /bin/bash.

2. The Command: echo

echo is one of the most fundamental commands in Bash. Its job is to display a line of text. Here, it's used to print the final formatted string to the standard output (your terminal).

3. The String: "One for ..., one for me."

The double quotes are crucial. In Bash, double quotes allow for variable and parameter expansion within the string. If we used single quotes ('...'), the contents would be treated as a literal string, and ${1:-you} would be printed exactly as written, which is not what we want.

4. The Magic: ${1:-you}

This is the core of the solution. Let's break this expression down even further.

• $1: This is the first positional parameter. It automatically holds the value of the first argument you pass to the script on the command line. In the example ./two_fer.sh Do-yun, the value of $1 is "Do-yun". If you run ./two_fer.sh with no arguments, $1 is unset.
• ${...}: The curly braces are used to explicitly define the boundaries of the parameter name. While you can often get away with just $1, it's a best practice to use ${1}. This prevents ambiguity, especially when the parameter is next to other characters, for example: echo "${1}st_place". Without braces, the shell would try to find a variable named $1st_place, which doesn't exist.
• :-you: This is the parameter expansion operator. The syntax is ${parameter:-defaultValue}. It works like this:
  • The shell checks the value of the parameter (in our case, 1).
  • If the parameter is unset or null (an empty string), the shell expands the expression to the defaultValue (in our case, "you").
  • Else (if the parameter has a value), the shell expands the expression to the parameter's actual value.

This simple operator is what allows the script to be so dynamic and concise. It's a built-in conditional statement designed specifically for this type of scenario.

Logic Flow Diagram

Here is a visual representation of the logic inside the ${1:-you} expansion. This flow chart illustrates the decision-making process the Bash shell goes through.

    ● Start Script Execution
    │
    ▼
  ┌──────────────────┐
  │  Evaluate the    │
  │  expression      │
  │  `${1:-you}`     │
  └─────────┬────────┘
            │
            ▼
  ◆ Is the first positional
    parameter (`$1`) unset or null?
   ╱                            ╲
 Yes (e.g., `./two_fer.sh`)      No (e.g., `./two_fer.sh Alice`)
  │                              │
  ▼                              ▼
┌────────────────────┐         ┌────────────────────┐
│ Expansion result   │         │ Expansion result   │
│ is the default     │         │ is the value of `$1` │
│ value: "you"       │         │ e.g., "Alice"      │
└─────────┬──────────┘         └─────────┬──────────┘
          │                              │
          └──────────────┬───────────────┘
                         │
                         ▼
        ┌──────────────────────────────────┐
        │ Substitute result into the echo  │
        │ string and print to the console. │
        └──────────────────────────────────┘
                         │
                         ▼
                      ● End

---

Where to Use This Pattern: Real-World Scenarios

The ${parameter:-default} pattern is not just for academic exercises. It is used constantly in professional scripts to create flexible and user-friendly tools. Here are a few practical examples.

1. Setting Default Configuration Values

Imagine a script that connects to a database. You might want to allow the user to specify a host, but default to localhost if they don't.

#!/usr/bin/env bash

# First argument is the database host, defaults to 'localhost'
DB_HOST=${1:-localhost}
DB_USER="admin"

echo "Connecting to database on host: ${DB_HOST} with user: ${DB_USER}..."
# ... database connection logic follows

Running it:

$ ./connect_db.sh db.prod.server.com
Connecting to database on host: db.prod.server.com with user: admin...

$ ./connect_db.sh
Connecting to database on host: localhost with user: admin...

2. Specifying a Default File Path

Consider a script that processes a log file. You can make it process a specific file passed as an argument, or a default system log file if no argument is given.

#!/usr/bin/env bash

# Set the log file to the first argument, or default to /var/log/syslog
LOG_FILE=${1:-/var/log/syslog}

echo "Analyzing log file: ${LOG_FILE}"
echo "-------------------------------------"
# Use `tail` to show the last 5 lines of the specified log file
tail -n 5 "${LOG_FILE}"

3. Greeting a User with a Default Name

You can write a simple script that greets a user by name, but calls them "Guest" if no name is supplied.

#!/usr/bin/env bash

USERNAME=${1:-Guest}

echo "Welcome to the system, ${USERNAME}!"

---

Beyond Defaults: Exploring Other Parameter Expansions

The :- operator is just one of several powerful parameter expansions available in Bash. Understanding the whole family of these operators will significantly elevate your scripting capabilities. They provide concise ways to handle variables, assign defaults, and even throw errors.

Here’s a quick-reference table of the most common substitution-style expansions:

Expansion	Name	Behavior
${param:-word}	Use Default Value	If param is unset or null, the expansion is word. The variable param itself is not changed.
${param:=word}	Assign Default Value	If param is unset or null, it is assigned the value of word, and the expansion is also word.
${param:?word}	Error if Unset or Null	If param is unset or null, the script prints word to standard error and exits. This is for mandatory parameters.
${param:+word}	Use Alternate Value	If param is set and not null, the expansion is word. If it's unset or null, the expansion is nothing (an empty string).

When to Use Each Operator

• Use :- (like in 'Two Fer') when you need a temporary default for a single command but don't want to modify the original variable. This is the most common use case.
• Use := when you want to set a default value for a variable that will be used multiple times throughout the script.

  
  # If LOG_LEVEL is not set, assign it 'INFO' for the rest of the script
  : "${LOG_LEVEL:=INFO}"
  echo "Logging level is set to: ${LOG_LEVEL}"
  # Some other part of the script...
  echo "Still logging at: ${LOG_LEVEL}"
          

• Use :? when an argument is absolutely mandatory for your script to function. This is better than a manual if check because it's more concise and idiomatic.

  
  # The script requires an input file to work.
  INPUT_FILE=${1:?"Error: Input file path is a required argument."}
  echo "Processing file: ${INPUT_FILE}"
          

• Use :+ in more niche scenarios, for example, to add a command-line flag only if a variable is set.

  
  # If VERBOSE is set to any value, add the '-v' flag to the command.
  VERBOSE_FLAG=${VERBOSE:+"-v"}
  some_command ${VERBOSE_FLAG} an_argument
          

Decision Flow for Choosing an Expansion

This diagram can help you decide which parameter expansion operator fits your needs.

    ● Start with a variable (e.g., `MY_VAR`)
    │
    ▼
  ◆ Do you need to handle the case where `MY_VAR` is unset or null?
   ╱                                                           ╲
 Yes                                                            No
  │                                                             │
  ▼                                                             ▼
◆ Is this missing value a critical, script-stopping error?      [ Proceed with `$MY_VAR` ]
   ╱                                       ╲
 Yes                                        No
  │                                         │
  ▼                                         ▼
┌──────────────────┐               ◆ Do you need to permanently set the default
│ Use `:?` to exit │                 value for `MY_VAR` for the rest of the script?
│ with an error.   │                ╱                                     ╲
│ `${MY_VAR:?msg}`  │              Yes                                      No
└──────────────────┘               │                                        │
                                   ▼                                        ▼
                             ┌──────────────────┐                       ┌──────────────────┐
                             │ Use `:=` to assign │                       │ Use `:-` for a   │
                             │ the default.     │                       │ temporary default. │
                             │ `${MY_VAR:=def}`  │                       │ `${MY_VAR:-def}`   │
                             └──────────────────┘                       └──────────────────┘

---

Pros and Cons of This Approach

While parameter expansion is powerful, it's essential to understand its advantages and potential pitfalls to use it effectively and maintain readable code.

Advantages

• Conciseness: It replaces a multi-line if-then-else block with a short, expressive piece of syntax, making scripts cleaner and easier to read at a glance.
• Efficiency: As a built-in shell feature, it is highly optimized and performs faster than forking a new process or running more complex conditional logic.
• Readability (for experienced scripters): Once you are familiar with the syntax, it becomes an idiomatic and instantly recognizable pattern for handling defaults.
• POSIX Compliance: The ${parameter:-word} syntax is part of the POSIX standard, meaning it's highly portable and will work in most shells like sh, bash, zsh, and ksh.

Risks and Considerations

• Can Hide Errors: Using :- or := can mask a problem. If a variable should have been set by a previous step and wasn't, providing a default might allow the script to continue in a broken state. In such cases, :? is the better choice.
• Cryptic for Beginners: The syntax can be intimidating for someone completely new to shell scripting. Proper code comments can help mitigate this.
• Reduced Readability with Nesting: While possible, nesting parameter expansions (e.g., ${VAR1:-${VAR2:-default}}) can quickly become very difficult to read and debug. For complex fallback logic, a traditional if statement is often clearer.

---

Frequently Asked Questions (FAQ)

1. What is the difference between $1 and ${1}?

Functionally, they are often the same. However, the curly braces ${1} provide explicit scoping. They tell the shell exactly where the variable name ends. This is essential to avoid ambiguity when the variable is immediately followed by other characters that could be part of a variable name, e.g., echo "${1}_file.txt" works, but echo "$1_file.txt" would fail because the shell would look for a variable named $1_file. Using braces is a recommended best practice for clarity and safety.

2. Why use #!/usr/bin/env bash instead of #!/bin/bash?

Hardcoding #!/bin/bash assumes that the Bash interpreter is always located at /bin/bash. This is true on many Linux systems, but not universal (e.g., on macOS with Homebrew, it might be in /usr/local/bin/bash). #!/usr/bin/env bash uses the env program to find the first bash executable in the user's $PATH, making the script more portable across different systems and user setups.

3. Can I use parameter expansion on my own variables, not just positional parameters?

Absolutely! Parameter expansion works on any variable. For example: MY_CONFIG=${CUSTOM_CONFIG:-"default.conf"}. This is a very common pattern for setting defaults for environment variables or variables defined within the script itself.

4. What happens if I provide an empty string, like ./two_fer.sh ""?

The :- operator triggers if the parameter is either unset OR null (an empty string). Therefore, running ./two_fer.sh "" will still result in the output One for you, one for me. because the empty string is treated as a null value in this context. If you need to distinguish between an unset variable and an empty one, you would need a more complex check using an if statement.

5. How is ${1:-you} different from ${1:=you}?

The key difference is assignment. :- (Use Default) only uses the default value for the expansion at that moment; it does not change the value of $1. := (Assign Default) both uses the default value for the expansion AND assigns that default value back to the variable $1 for future use in the script. You cannot assign to positional parameters, so ${1:=you} would actually produce an error. This operator is intended for regular variables, not $1, $2, etc.

6. Is there another way to solve the 'Two Fer' problem in Bash?

Yes, you could use a standard if statement. It's more verbose but can be clearer for beginners. The equivalent logic would look like this:

#!/usr/bin/env bash
if [ -z "$1" ]; then
  # The -z flag checks if the string is null (zero length)
  name="you"
else
  name="$1"
fi
echo "One for ${name}, one for me."
    

As you can see, the parameter expansion version is much more compact.

---

Conclusion: From a Simple Cookie to Powerful Scripts

The 'Two Fer' problem, sourced from the kodikra.com learning path, serves as a perfect introduction to a concept with far-reaching implications. What begins as a simple task of generating a sentence reveals a powerful, idiomatic Bash feature for building resilient and flexible scripts. By mastering ${parameter:-default} and its variants, you elevate your code from brittle to robust.

You now have the toolset to handle optional inputs, set sane configuration defaults, and write scripts that don't fail unexpectedly. This is a fundamental skill for anyone working in system administration, cloud engineering, DevOps, or any field that relies on the command line. The elegance of solving a problem in a single, expressive line of code is a hallmark of a skilled scripter.

Ready to build on this foundation? Explore the complete Bash learning path on kodikra.com to tackle more advanced challenges and solidify your journey to scripting mastery. For more comprehensive guides and examples, visit our main Bash language resource page.

Disclaimer: The code and explanations in this guide are based on modern Bash versions (4.x and higher). While the core parameter expansion features are POSIX-compliant, behavior in very old or non-standard shells may vary.

---

Published by Kodikra — Your trusted Bash learning resource.