Before You Reach for sed: Master Bash Parameter Expansion

Ishe Chinyoka

- 4 minutes read

Table of Contents

Yesterday we revisited Perl and saw why dedicated text-processing languages still have an important place in the textsmith’s toolbox. Today, we move to the opposite end of the spectrum. Before reaching for Perl, sed, or awk, it is worth asking a simpler question: can the shell already do what we need? More often than many people realize, the answer is yes.

Most beginners—including me—learn shell scripting by chaining together familiar commands. Need to replace a word? Call sed. Need to trim a filename? Use cut or awk. Need to extract an extension? Perhaps another pipeline.

Then one day you discover parameter expansion.

Suddenly you realize that many operations you have been launching external programs for can be performed by Bash itself.

For a textsmith, this is an important moment.

The Shell Already Understands Strings

A shell variable is more than a container for text. Bash knows how to examine it, shorten it, replace parts of it, measure its length, and even transform its case.

Instead of thinking,

“Which command should I call?”

you begin asking,

“Can Bash already do this?”

Often, the answer is yes.

Consider a filename stored in a variable:

file="report-final-draft.md"

Need to remove the extension?

echo "${file%.md}"

Need to remove everything after the first hyphen?

echo "${file%%-*}"

Need to replace one word?

echo "${file/draft/final}"

Need to replace every occurrence?

echo "${file//-/_}"

No subprocesses.

No pipes.

No temporary files.

Just the shell.

Why This Matters

Launching another program is not always expensive, but it is another moving part.

When your script becomes

echo "$file" | sed ...

the shell has to:

  • start another process,
  • pass data to it,
  • wait for it to finish,
  • collect its output.

Sometimes that is exactly the right thing to do.

Sometimes it is unnecessary.

Parameter expansion keeps simple operations inside the shell itself.

The result is often shorter, clearer, and easier to read.

Textsmithing Is About Choosing the Right Tool

This is not an argument against sed or awk.

Far from it.

Those tools remain among the greatest text-processing languages ever created.

Need regular expressions?

Use sed.

Need record processing?

Use awk.

Need to transform thousands of lines in a file?

Those are still your trusted companions.

But many shell scripts never operate on files.

They manipulate filenames.

Paths.

URLs.

Configuration values.

Environment variables.

Command-line arguments.

For these tasks, parameter expansion is frequently the better choice.

Everyday Examples

Suppose you are processing backups.

backup="database-2026-07-31.tar.gz"

Extract the base name:

echo "${backup%.tar.gz}"

Rename hyphens to underscores:

echo "${backup//-/_}"

Convert a variable to uppercase:

echo "${backup^^}"

Or lowercase:

echo "${backup,,}"

Measure its length:

echo "${#backup}"

None of these require another command.

Working with Paths

Textsmiths constantly work with paths.

Bash understands these surprisingly well.

Suppose:

path="/home/textsmith/Documents/report.md"

Get only the filename:

echo "${path##*/}"

Remove the filename:

echo "${path%/*}"

These examples replace what many people instinctively solve with basename and dirname.

Those commands remain useful—especially in portable POSIX scripts—but inside Bash scripts, parameter expansion is often the more direct solution.

Faster to Read, Easier to Maintain

One pleasant side effect of learning these expansions is that your scripts become more declarative.

Compare these approaches.

Using an external command:

filename=$(basename "$path")

Using parameter expansion:

filename="${path##*/}"

The second line says exactly what is happening: remove everything up to the final slash.

Once you become familiar with the syntax, you begin recognizing these patterns immediately.

A Skill That Travels

Even if Bash is not your daily shell, this knowledge remains valuable.

Many Linux systems still use Bash extensively.

Countless automation scripts assume Bash.

Continuous integration pipelines frequently invoke Bash.

Even users who prefer Zsh will recognize many of these parameter expansions, as Zsh supports similar—and in some cases even more powerful—forms of parameter expansion.

Learning Bash’s string manipulation is therefore not learning an obscure dialect. It is learning a family of techniques that will accompany you across many Unix-like systems.

Learn Both Worlds

There is a temptation in computing to choose sides.

“Always use sed.”

“Never use shell features.”

“Everything should be done with awk.”

Experienced textsmiths rarely think this way.

The Unix tradition has never been about blind loyalty to a particular tool. It is about understanding what each tool does best.

Sometimes the shell should call another program.

Sometimes the shell already has everything it needs.

Wisdom lies in knowing the difference.

The Textsmith’s Lesson

One of the marks of an experienced shell programmer is not the number of commands they know, but the number of unnecessary commands they no longer write.

Parameter expansion will never replace sed.

It will never replace awk.

Nor should it.

Instead, it fills the surprisingly large space between simple variable manipulation and full-scale text processing.

The more fluent you become with Bash’s native string manipulation, the more naturally your scripts flow. They become shorter, clearer, and more expressive—not because they use fewer tools, but because they use each tool where it belongs.

For the textsmith, that is perhaps the greatest lesson of all: master the language of your shell before reaching for another language outside it.