Shell Escape Tool

You are writing a shell script and need to pass a user-supplied path as an argument to rm. The path is /home/user/My Documents/file.txt. The space in My Documents will split the argument into two — and rm will try to delete My and Documents/file.txt instead. This tool wraps the path in single quotes ('/home/user/My Documents/file.txt'), making it a single argument the shell passes intact to the command.

Why Shell Escaping Is Different

Unlike JSON or URL encoding, shell escaping has no single universal algorithm. The shell — bash, sh, zsh, dash — interprets special characters during command parsing. Different characters are special in different quoting contexts. The safest approach is quoting rather than character-by-character escaping.

The POSIX shell specification defines three quoting mechanisms, and this tool supports all three:

Method 1: Single-Quote Wrapping (Recommended)

Single quotes are the most powerful and predictable escaping method. Inside single quotes, every character is literal — no special characters, no variable expansion, no command substitution, nothing. The shell does not even look at the content.

echo 'Hello! $USER `whoami` & more'
# Output: Hello! $USER `whoami` & more

The only character that cannot appear inside single quotes is a literal single quote. If the string itself contains a ', you must break out of the single-quote context, insert the quote, and re-enter:

echo 'it'\''s fine'
# Output: it's fine

The pattern '\'' works like this:

1. ' — end the current single-quoted string
2. \' — this is outside the string now; \' is a backslash-escaped single quote… wait, backslash doesn’t work outside quotes either in some shells. The reliable form is: '"'"' (end quote, double-quote-wrap a single quote, start quote again)

This tool uses the '"'"' form which is universally portable across POSIX shells.

Method 2: Double-Quote Wrapping

Double quotes allow variable expansion and command substitution to pass through, while escaping other special characters. Inside double quotes, the shell still interprets:

• $VAR and ${VAR} — variable expansion
• $(cmd) — command substitution
• `cmd` — backtick command substitution
• $((expr)) — arithmetic expansion
• \ — escape character (only before $, `, ", \, and newline)

This tool escapes $, `, \, !, and " — the characters that remain active inside double quotes. Use this method when you intentionally want variable expansion to occur.

name="World"
echo "Hello, $name!"      # Hello, World!  (expansion works)
echo "Cost: \$5"          # Cost: $5       ($ escaped, no expansion)
echo "A \"quoted\" word"  # A "quoted" word

Warning about !: In interactive bash, ! triggers history expansion inside double quotes. Escaping it as \! suppresses this. In non-interactive scripts (the common case for generated shell commands), history expansion is disabled by default and ! is safe unescaped.

Method 3: Backslash Escaping

Without any quotes, each special character is individually preceded by a backslash. Backslash tells the shell to treat the next character literally.

echo Hello\ World\!\ \$USER
# Output: Hello World! $USER

Backslash escaping produces readable output for simple strings (paths, identifiers) but becomes verbose and hard to read for strings with many special characters. It is best suited for short strings or when you want to see exactly which characters are being escaped.

Shell Special Characters

These characters have special meaning in unquoted bash/sh contexts and must be escaped when used as literal values:

SPACE  !  "  #  $  &  '  (  )  *  ,  :  ;  <  =  >  ?
@  [  \  ]  ^  `  {  |  }  ~

A few that surprise developers:

!: History expansion in interactive bash. Requires escaping in double-quoted strings in interactive sessions.

#: Starts a comment in unquoted context. echo a#b works fine; echo a #b silently drops #b.

* and ?: Glob wildcards. rm *.log deletes all .log files — rm '*.log' tries to delete a file literally named *.log.

~: Tilde expansion. Unquoted ~ expands to the home directory. echo ~/file → /home/user/file. echo '~/file' → ~/file (literal).

$IFS: The Internal Field Separator controls word splitting. Spaces, tabs, and newlines in unquoted strings trigger splitting. Quoting prevents word splitting entirely.

Safe Argument Passing in Scripts

When writing shell scripts that accept external input (from users, files, or other programs), always quote variable expansions:

# Dangerous: word splitting + glob expansion
rm $filename

# Safe: always quote variable expansions
rm "$filename"

# Even safer: use -- to prevent filename being treated as an option
rm -- "$filename"

The "$variable" form preserves the exact value including spaces and special characters. $variable without quotes is almost always a bug when the value may contain spaces.

Practical Examples

Passing a file path with spaces:

# Escaped by this tool (single-quote method):
cp '/home/alice/My Documents/report Q4.pdf' /backup/

A curl URL with query parameters:

# Unescaped: breaks on & (shell runs background job)
curl https://api.example.com/search?q=hello&page=2

# Escaped (single-quote method):
curl 'https://api.example.com/search?q=hello&page=2'

A grep pattern with special regex characters:

# Escaped (single-quote method, regex passed literally):
grep -r 'function\s*(' src/

Frequently Asked Questions

Which method should I use? Single-quote wrapping in almost all cases. It is the safest, most predictable, and universally supported across all POSIX shells. Only use double-quote wrapping when you specifically need variable expansion to occur inside the string.

Does this work for zsh, fish, or Windows PowerShell? This tool targets POSIX sh / bash quoting rules, which are also valid in zsh. Fish shell uses different syntax. Windows PowerShell has entirely different quoting rules — for PowerShell, use the JavaScript escape tool with single-quote style as a rough approximation, but prefer using PowerShell’s [System.Management.Automation.WildcardPattern]::Escape() or similar for proper escaping.

What about newlines in arguments? Newlines can be passed as shell arguments using $'...' syntax (ANSI-C quoting, bash extension): $'line1\nline2'. Standard POSIX sh does not have a clean way to pass newlines in arguments — use a file or process substitution instead.

Is this tool sufficient to prevent shell injection? Single-quote escaping (as implemented here) is correct for POSIX shell string arguments. However, the safest approach for shell injection prevention in application code is to avoid constructing shell command strings entirely. Use language-level APIs that take arguments as arrays: subprocess.run(['rm', filename]) in Python, child_process.execFile in Node.js, etc.

Related Tools

• JSON Escape / Unescape — escape strings for JSON string values
• URL Encoder / Decoder — percent-encode strings for URLs
• Regex Tester — test regular expressions (including those you might pass to grep or sed)
• Chmod Calculator — Unix file permission calculator