🐚 Bash CLI Text Escaper

📝
🔧
{{ escapeModeDescription }}
⚙️
📚
📤
💡
{{ getBashExample() }}
Ready to use in your bash script or terminal
📊
Input length: {{ inputText.length }} characters
Output length: {{ outputText.length }} characters
Mode: {{ reverseMode ?'Unescape' :'Escape' }} ({{ escapeMode }})
⚠️ Contains spaces
⚠️ Contains dollar signs (variable expansion)
⚠️ Contains shell metacharacters
⚠️ Contains quotes
⚠️

ℹ️ About Bash CLI Text Escaper

Bash CLI Text Escaper turns arbitrary text into a shell word that can be pasted into a Bash command or script as data. Shell quoting removes the special meaning of characters such as spaces, pipes, semicolons, dollar signs, quotes, command substitutions, and glob patterns so the shell parser does not split or execute the value unexpectedly. The rules are based on the quoting behavior documented by the GNU Bash manual and the POSIX Shell Command Language.

Common shell escaping use cases:

  • Quote file paths, directory names, and backup labels that contain spaces, quotes, or glob characters.
  • Pass JSON, URLs, regular expressions, SQL fragments, or search strings as one command-line argument.
  • Prepare values for ssh, curl, printf, grep, find, and deployment scripts.
  • Turn copied log lines or user-provided strings into literal shell arguments before testing a command.

Escape modes:

  • Single quotes: The safest default for literal data. Everything inside is preserved except a literal single quote, which must be represented by closing the quote, escaping one quote, and reopening it.
  • Double quotes: Useful when you intentionally want selected shell expansion behavior, but $, backticks, backslash, and double quotes still need care.
  • Backslash escaping: Prefixes individual metacharacters with \. This is readable for short strings but harder to audit for long pasted values.
  • ANSI-C quoting: Bash $'...' syntax for control characters and byte-style escapes such as \n, \t, and \x00; see the Bash ANSI-C quoting reference.

Technical details:

  • Shell metacharacters include |, &, ;, <, >, (, ), $, backticks, \, quotes, spaces, tabs, and newlines.
  • Conditional metacharacters such as *, ?, [, ], !, #, ~, and {} may also need quoting depending on context.
  • Escaping affects shell parsing only. It does not validate command names, option meanings, remote shell layers, SQL syntax, JSON syntax, or application-level authorization.
  • POSIX sh supports backslash, single-quote, and double-quote forms; Bash-specific $'...' quoting is not portable to every shell.

Examples:

  • Project Files/report final.txt becomes 'Project Files/report final.txt' in single-quote mode.
  • name=O'Reilly & Sons becomes a single shell word instead of splitting at the space, quote, or ampersand.
  • {"path":"$HOME/*.log"} can be quoted so $HOME is not expanded and * is not treated as a glob.

Limitations: Escaped output is meant for one shell argument, not for building an entire trusted command line from untrusted pieces. Re-escaping may be required when a value passes through multiple parsers, such as a local shell, ssh, sudo sh -c, YAML, JSON, Make, or CI runner interpolation. Review the final command in the exact shell and operating environment where it will run.

Security warning: Escaping is a last line of defense, not a complete command-injection control. When writing software, prefer APIs that pass the executable and each argument separately, validate allowed commands and options, and avoid invoking a shell for untrusted input. The OWASP OS Command Injection Defense Cheat Sheet explains why argument separation and allow-list validation are safer than composing shell strings.

API Usage Example:

POST /api/tools/text/bash-escaper
Content-Type: application/json

{
    "text": "text to escape",
    "mode": "single",
    "reverse": false
}
Ready