Bash

An overview of Bash metacharacters, their functions, and how they influence parsing, expansion, and execution in Unix‑like environments

The following table provides an overview of meta‑characters commonly used in both the Bourne shell and the C shell. To improve completeness, several compound character sequences have also been included.

While the table offers a broad reference, it does not cover every nuance of shell behavior. Shell meta‑characters can interact in subtle and sometimes unexpected ways, which is important to keep in mind when analyzing or constructing command sequences in a security context.

Bash set Options

Bash’s set built‑in modifies shell behavior by enabling or disabling specific execution modes.
These flags are essential for debugging, error handling, safety, and strict scripting.

Bash Redirection Operators

Bash uses redirection operators to control where input comes from and where output goes. These symbols allow you to route standard input, standard output, and error output to files, devices, or other commands.

Bash Special Characters

These characters define how Bash interprets commands, arguments, quoting, variables, job control, and file descriptors.

A solid understanding of shell meta‑characters is essential when working in Unix‑like environments, particularly in security‑focused contexts. Throughout this material, we will also look at practical methods for verifying how the shell interprets these characters, enabling you to identify where unexpected behavior originates.

Most keyboards provide three different types of quotation marks. Two of them — the single quote (') and the double quote (") — are the same characters used for standard English punctuation, and both play important roles in controlling how the shell processes text. The third character, the backtick (`), is visually similar to the single quote, which often leads to confusion in shell scripts.

Despite the resemblance, the backtick does not serve as a quoting mechanism.

Instead, the backtick is used for command substitution. Any text enclosed within backticks is executed by the shell, and the resulting output is inserted directly into the surrounding command.

• For example:

  result=`command`
  

A precise understanding of how these characters behave — and how the shell interprets them under different conditions — is fundamental in offensive security work. Meta‑characters control parsing, expansion, redirection, and execution flow, and even small misunderstandings can lead to unexpected command behavior.

For an attacker, these mechanics are tools; for a defender, they are potential entry points.

Mastering these distinctions is essential when crafting payloads, bypassing filters, manipulating input vectors, or analyzing how a target system processes user‑supplied data.

Whether you are building reliable exploitation chains, testing for injection vulnerabilities, or tracing how a command is being parsed during debugging, knowing exactly how the shell treats each character is what allows you to predict — and control — the outcome.

Process Substitution <( ) och >( )

This is one of Bash's most powerful features, but almost no one documents it properly.

Example:

diff <(sort file1) <(sort file2)

It is important for:

• pipelines
• OSINT tools
• data comparisons
• advanced automation

Arrays & Associative Arrays

It is important because arrays solve:

• dynamic variables
• eval problems
• complex data handling
• output parsing

Example:

arr=(one two three)
declare -A map=([key]=value)

Here‑Strings `<<<``

Example:

grep foo <<< "bar foo baz"

POSIX vs Bash Differences

This is important for portability and security.

ShellCheck Best Practices

• Always quote variables
• Prefer [[ ]] over [ ]
• Avoid echo -e
• Use printf
• Avoid eval

Debugging Techniques

• set -x
• PS4='+ \({BASH_SOURCE}:\): '}:${FUNCNAME[0]
• declare -p
• trap 'echo error at $LINENO' ERR

This is advanced but extremely useful.

Subshells vs Groups

You have the table, but an explanatory section would make it complete:

• `( )``-> subshell
• `{ }``-> same shell

It is important for:

• variable scope
• performance
• pipelines

Arithmetic & Integer Handling

(( x++ ))
let x+=1
x=$((x+1))

And the difference between:

• integer context
• string context

Signals & Traps

This is important for:

• cleanup
• security
• robust scripts
• debugging

A table of signals (INT, TERM, EXIT, HUP):

trap 'cleanup' EXIT

#!/usr/bin/env bash

# Create a cleanup function
cleanup() {
    local exit_code=$? # Spara den sista exit-koden
    
    # 1. Kill background processes (like your spinner)
    [[ -n ${spinner_pid} ]] && kill "${spinner_pid}" 2>/dev/null
    
    # 2. Delete temp files
    rm -f "${tmp_batch}" "${count_tmp}"
    
    # 3. Log exit (optional)
    if [[ ${exit_code} -ne 0 ]]; then
        printf "\n${RED}Skriptet avbröts oväntat (Code: %d)${RST}\n" "${exit_code}"
    fi

    exit "${exit_code}"
}

# Set your trap for all relevant signals
# We include EXIT so that it cleans up even if the script finishes
trap 'cleanup' INT TERM HUP EXIT

Why this is better than trap rm file EXIT:

Captures Exit Code: - By getting $? the first thing you do in the function, you know why the script died.

Portability: - EXIT works in almost all shells, but adding INT and TERM ensures that the cleanup happens immediately when the signal is received, instead of waiting for Bash to catch up to the exit stage.

Cleanliness: - You don't have to have long lines of commands inside the trap string itself.

An important detail: SIGKILL (kill -9) - Remember that SIGKILL (-9) cannot be caught. If someone runs kill -9 on your script, no trap in the world will be executed.

Therefore, you should always use TERM (the default) when you want to terminate something gracefully.

Exit Codes & Error Propagation

From file: /usr/include/sysexits.h

• $?
• set -e pitfalls
• pipelines
• PIPESTATUS
• || vs &&

This is important for robust scripts.

Examples of Bourne shell filename expansions

English Terms

Basic Bash Symbols

Dessa är byggstenarna i nästan alla scripts.

Test and Comparison Operators

Dessa används i if, while, [[ ]], [ ] och case.

Loops, Blocks, and Grouping

Pipes, Redirection, and Background Jobs

Control Structures

Kontrollstrukturer

Understanding eval in Bash

eval is one of the most misunderstood, yet most powerful — and dangerous — commands in Bash. It effectively gives the shell a second chance to interpret a string as code. This allows you to construct dynamic commands, but it also opens the door to command injection, unexpected expansions, and behaviors that would otherwise be impossible.

This section explains:

• why eval is dangerous
• when its use is legitimate
• the common pitfalls
• how to avoid unsafe patterns

Why eval can break root‑checks

Many beginner scripts attempt to check for root privileges like this:

if [ "$USER" = "root" ]; then
    echo "Running as root"
fi

This is unsafe because:

• $USER is just an environment variable
• it can be modified by the user
• it does not reflect the real UID
• it should never be used to determine privilege level
• and the situation becomes even worse when eval is involved

How eval makes the problem worse

eval "check_user=$USER"

Two things happen:

• $USER expands before eval runs
• eval executes the resulting string as code
• This means an attacker can manipulate $USER so that eval executes something entirely different from what the developer intended.
• eval allows an attacker to inject code directly into the root‑check logic.

Safe, abstract example (non‑harmful)

Suppose a script contains:

eval "current_user=$USER"

A user can set:

export USER='root some_other_stuff'

Or even something that causes eval to execute additional commands.

Because eval executes the string as code, an attacker can:

• modify script logic
• make the script believe the user is root
• inject arbitrary commands

“If you use eval with untrusted data, you have already lost.”

Why this happens

1) $USER is not a trustworthy source

It is just an environment variable and can be set to anything.

2) eval performs double expansion

This allows an attacker to:

• break out of the intended string
• inject additional code
• modify variables

• alter script logic

• Root checks must be based on UID, not variables

The only safe way to check for root is:

if [ "$(id -u)" -eq 0 ]; then

This cannot be manipulated through environment variables.

This cannot be manipulated through environment variables.

if [ "$(id -u)" -eq 0 ]; then
    echo "Running as root"
fi

Never use eval on data coming from:

• user input
• environment variables
• files
• command‑line arguments
• network data

Avoid eval entirely unless you fully understand the expansion order and trust the input.

Summary

• eval allows attackers to inject code into your script.
• $USER is not a safe indicator of root privileges.
• Combining eval with $USER is a classic security trap.
• It can make a script believe the user is root.
• The only safe root check is id -u.

Can eval “fake” UID 0?

No - eval can never change the actual UID.

UID is stored in the kernel’s process table. The shell cannot modify it, and eval cannot modify it.

This means:

• id -u always shows the real UID
• whoami always shows the real username
• eval cannot grant root privileges
• eval cannot bypass kernel‑level checks

So the system remains safe.

But eval can fool a poorly written script into thinking the user is root.

How eval can fool a root‑check (without changing UID)

eval "current_user=$USER"
if [ "$current_user" = "root" ]; then
    echo "You are root"
fi

A user can simply do:

export USER='root'

The script now believes the user is root, even though:

id -u

still returns a non‑root UID (e.g., 1000).

It becomes even worse if the script does something like:

eval "$USER_check"

An attacker can set:

export USER_check='current_user=root'

eval then executes attacker‑controlled code, altering the script’s logic.

Again: this does not change the real UID - it only manipulates the script’s behavior.

Why this happens

1) $USER is not a secure indicator

It is user‑controlled.

2) eval executes attacker‑controlled text as code

This allows:

• variable manipulation
• logic modification
• command injection

3) The script uses the wrong method for privilege checks

The only correct method is:

if [ "$(id -u)" -eq 0 ]; then

Correct approach

if [ "$(id -u)" -eq 0 ]; then
    echo "Running as root"
fi

Never use eval on data from:

• environment variables
• user input
• arguments
• files
• network sources

Avoid eval unless absolutely necessary.

Summary

eval cannot change the real UID. eval cannot grant root privileges. eval can trick a poorly written script into believing the user is root. * This happens when scripts rely on $USER or other environment variables for privilege checks. * The only safe method is id -u.

Bash Commands

bash -c "help set"

bash --debug

bash --debugger

bash --dump-po-strings

bash --dump-strings

bash --help

bash --init-file

bash --login

bash --noediting

bash --noprofile

bash --norc

bash --posix

bash --pretty-print

bash --rcfile

bash --restricted

bash --verbose

bash --version