Re: Bug Report: Escaped backslash incorrectly reinterpreted as control escape in double-quoted strings

[Philippe Altherr <philippe.altherr@xxxxxxxxx>]

When you run the command echo "X\\tX", there are two levels of parsing. First the Zsh shell parses the string "X\\tX" into the 4 characters X, <backslash>, t, and X. Then, Zsh's builtin echo does its own parsing; it recognizes the sequence <backslash>, t as an escape sequence and replaces it with the character <tab>. That's why this command prints the 3 characters X, <tab>, and X. You can disable the echo's parsing with the -E flag. Thus, echo -E "X\\tX" prints the 4 characters X, <backslash>, t, and X.

Zsh's builtin printf and most (all?) external printf commands also do their own parsing and replace the sequence <backslash>, t with the character <tab>. Bash's echo builtin doesn't by default but you can force it to do it with the flag -e. Thus, Bash's echo -e "X\\tX", behaves like Zsh's echo "X\\tX".

Philippe

On Wed, Nov 26, 2025 at 2:20 PM Jelius Basumatary <personal@xxxxxxxxxx> wrote:

Hi,

I’m aware of the documentation saying “\\” can be used to print a backslash but the issue here is that if there is a recognized character (\e, \n, \t) after the backslash it treats it as an escape sequence eve though the backslash was previously escaped. 

Example: “\\t…” instead of printing “\t…” it would print “       ….” even if the backslash was escaped, also bash prints it correctly as “\t…” .

About the use of AI to write the mail, it was only used to draft the mail as English is not my first language and there may be grammar mistakes in what I was writing. 

If this is an expected behavior then I apologize for wasting your precious time.

On 26 Nov 2025, at 3:59 PM, Mikael Magnusson <mikachu@xxxxxxxxx> wrote:



Hi,

This is not a bug, but the default behavior of echo in zsh as documented. Also, was this mail generated by AI? If so, please do not ever send bug reports generated by AI.

On Wed, Nov 26, 2025 at 9:02 AM Jelius Basumatary <personal@xxxxxxxxxx> wrote:

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:

1. \\ → literal \ (escaped backslash)
2. b → literal b
3. Final result: \b (two literal characters)

Instead, zsh appears to:

1. Process \\ → literal \ ✓
2. Reprocess the literal \ combined with b as \b → backspace control character (0x08) ✗
3. 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:

1. The \\slog vs \\blog comparison showing the inconsistency
2. 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

--

Mikael Magnusson