Here Documents vs Here Strings in Bash

You want to pass a multiline config or SQL statement to a command in bash. You could use echo with escapes and multiple lines, which is unreadable garbage. Or you could use a here document, which is clean and readable.

Here documents (<<EOF) and here strings (<<<) are bash features that solve the “pass text to a command” problem. Most people don’t know they exist. Here’s the thing: once you use them, you’ll never go back to chaining echo commands.

Here Documents: The Basics

A here document passes multiline text to a command:

#!/bin/bash

cat <<EOF
This is line 1
This is line 2
This is line 3
EOF

$ bash simple_heredoc.sh
This is line 1
This is line 2
This is line 3

The <<EOF starts the here document. Everything until the closing EOF is passed as input to cat. No escaping needed.

You can redirect to any command:

#!/bin/bash

wc -l <<EOF
Line 1
Line 2
Line 3
EOF

$ bash heredoc_to_command.sh
       3

Or to a file:

#!/bin/bash

cat > /tmp/config.txt <<EOF
server {
    listen 80;
    server_name example.com;
}
EOF

$ bash heredoc_to_file.sh
$ cat /tmp/config.txt
server {
    listen 80;
    server_name example.com;
}

The Indentation Problem: <<-EOF

Here documents usually start at column 0. If your script is indented (inside a function or if block), it looks weird:

#!/bin/bash

if true; then
cat <<EOF
This text
starts at column 0
EOF
fi

The closing EOF has to be at column 0, which breaks indentation. Use <<-EOF instead:

#!/bin/bash

if true; then
    cat <<-EOF
    This text
    can be indented
    EOF
fi

With <<-, the closing delimiter can be indented (tabs are stripped). Much cleaner.

Suppressing Variable Expansion

By default, variables in here documents are expanded:

#!/bin/bash

name="Alice"
cat <<EOF
Hello $name
EOF

$ bash expand_vars.sh
Hello Alice

If you want literal $name, quote the opening delimiter:

#!/bin/bash

name="Alice"
cat <<'EOF'
Hello $name
EOF

$ bash no_expand.sh
Hello $name

The quotes tell bash: don’t expand variables in this here document.

Piping Here Documents

Pipe the output to another command:

#!/bin/bash

cat <<EOF | grep "test"
This is a test
Not a match
Another test
EOF

$ bash pipe_heredoc.sh
This is a test
Another test

Or send to a command that reads stdin:

#!/bin/bash

mysql -u root -p <<EOF
CREATE DATABASE newdb;
USE newdb;
CREATE TABLE users (id INT, name VARCHAR(255));
EOF

No interactive prompts, clean SQL.

Here Strings: Single-Line Version

For single lines, use here strings (<<<):

#!/bin/bash

wc -w <<<'hello world test'

$ bash heredoc_string.sh
       3

That’s equivalent to:

$ echo 'hello world test' | wc -w
       3

But cleaner. No forking an echo process.

With variables:

#!/bin/bash

text="hello world"
grep "hello" <<<$text

Here strings are useful for passing data to commands that expect input without spawning echo.

Real-World Example 1: Config File Generation

#!/bin/bash

domain="example.com"
email="admin@example.com"

cat > /etc/nginx/sites-available/$domain <<-EOF
    server {
        listen 80;
        server_name $domain;

        location / {
            proxy_pass http://localhost:3000;
        }

        # Auto-generated: $(date)
        # Maintainer: $email
    }
EOF

echo "Config created for $domain"

The config is readable, variables are interpolated, and it’s all in one block.

Real-World Example 2: Database Setup

#!/bin/bash

DB_USER="app"
DB_PASS="secure_password"
DB_NAME="myapp"

mysql -u root -p<<-EOF
    CREATE USER '$DB_USER'@'localhost' IDENTIFIED BY '$DB_PASS';
    CREATE DATABASE $DB_NAME;
    GRANT ALL PRIVILEGES ON $DB_NAME.* TO '$DB_USER'@'localhost';
    FLUSH PRIVILEGES;
EOF

echo "Database and user created"

Clean, readable SQL. No escape nightmare.

Real-World Example 3: Multiline Variables

Store multiline text in a variable:

#!/bin/bash

readme=$(cat <<-EOF
    # My Project

    This is a readme file.
    It has multiple lines.
    All stored in a variable.
EOF
)

echo "$readme"

$ bash multiline_var.sh
# My Project

This is a readme file.
It has multiple lines.
All stored in a variable.

Difference: EOF vs Other Delimiters

You don’t have to use EOF. Any word works:

#!/bin/bash

cat <<SCRIPT
#!/bin/bash
echo "This is bash code"
SCRIPT

Use a different delimiter if the content contains EOF:

#!/bin/bash

cat <<'MARKER'
This contains EOF but won't be confused
with the actual EOF delimiter
MARKER

Suppressing Trailing Newline

By default, here documents add a trailing newline. To avoid it, use read:

#!/bin/bash

result=$(cat <<EOF
no newline at end
EOF
)

# But this adds a newline from the variable expansion
# To truly remove it, use read -d ''

read -d '' result <<EOF
no newline
EOF

echo "Result length: ${#result}"

Usually not worth the complexity, but it’s there if you need it.

The Pattern: Use Heredocs for Readability

BAD:

echo "server {" > config.txt
echo "    listen 80;" >> config.txt
echo "    server_name example.com;" >> config.txt
echo "}" >> config.txt

GOOD:

cat > config.txt <<-EOF
server {
    listen 80;
    server_name example.com;
}
EOF

The second is readable. The first is unmaintainable garbage.

The One Thing

Next time you want to write multiline text in bash, use:

#!/bin/bash

# For multiline with variable expansion
cat <<-EOF
    Your content here
    Variable: $VAR
    Can span lines
EOF

# For multiline without expansion
cat <<-'EOF'
    Your content here
    Literal: $VAR (not expanded)
    Can span lines
EOF

# For single line
command <<<'your input here'