Hello Zsh Development Team,
I'm reporting a bug in zsh's handling of escaped backslashes within double-quoted strings. When \\b appears in a double-quoted string, zsh incorrectly processes it as a backspace control character, even though the backslash has been properly escaped.
Environment
- Zsh version: 5.9
- Terminal: Ghostty
- OS: Ubuntu 24.04
- Comparison: This bug does NOT occur in bash - bash handles the same input correctly
Minimal Reproduction
The bug is clearly demonstrated by comparing two nearly identical commands:
echo "\`\\slog\\\`"
Expected output: `\slog\`
Actual output: `\slog\` ✓ (works correctly)
echo"\`\\blog\\\`"
Expected output: `\blog\`
Actual output: log\` ✗ (incorrect - backspace eats preceding characters)
Analysis
The sequence \\b should produce:
\\ → literal \ (escaped backslash)b → literal b- Final result:
\b (two literal characters)
Instead, zsh appears to:
- Process
\\ → literal \ ✓
- Reprocess the literal
\ combined with b as \b → backspace control character (0x08) ✗
- The backspace then erases preceding text
This is a Parser Bug, Not a Builtin Issue
I've confirmed that both echo and printf exhibit identical behavior, proving this occurs during quote parsing before command execution:
printf "xyz \`\\blog\\\` \\n"
# Output: xyz log\`
echo printf "xyz \`\\slog\\\` \\n"
# Output: xyz `\slog\`
Both produce the same incorrect output, confirming the bug is in zsh's double-quote parser.
Inconsistent Behavior
The bug only affects certain characters:
| Input |
Expected |
Actual |
\\s |
\s |
\s ✓ |
\\x |
\x |
hex escape prefix ✗ |
\\b |
\b |
backspace control char ✗ |
\\t |
\t |
inserts a tab character✗ |
\\n |
\n |
inserts a new line ✗ |
The correctness of escaping depends on which character follows the escaped backslash, which violates fundamental escaping semantics.
Bash Comparison
The same commands work correctly in bash:
# In bash:
echo "\`\\blog\\\`"
# Output: `\blog\` ✓ (correct)
Expected Behavior
Once a backslash has been escaped with \\, it should become literal and must not participate in further escape recognition. This is standard escaping behavior across all programming languages and shells.
Affected Use Cases
This bug affects:
- Scripts outputting literal paths or strings containing
\b, \a, \f, etc.
- Data serialization and logging
- Any code dynamically constructing strings with backslashes
- Cross-shell compatibility
Technical Description
The bug appears to be a double-processing issue where zsh's escape processor runs after escape consumption in double-quoted strings, allowing already-escaped backslashes to trigger control escapes on a second pass when followed by specific characters that form C-style escape sequences.
I've attached screenshots demonstrating:
- The
\\slog vs \\blog comparison showing the inconsistency
- Both
echo and printf producing identical incorrect output, proving this is a parser issue
Please let me know if you need any additional information or test cases.
Thank you for maintaining zsh!
Best regards,
Jelius