Issue with Entering Standalone Diacritic Characters - Data Loss Risk

[mjkno]

Windows Terminal version

1.20.10303.0

Windows build number

10.0.19045.3930

Other Software

WSL2 2.0.9.0, Ubuntu 20.04.6, zsh 5.8 (x86_64-ubuntu-linux-gnu), GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)

Steps to reproduce

1. Open Linux session on Windows Terminal.
2. Attempt to input a standalone diacritic character by pressing the corresponding dead key followed by the spacebar. For example, to enter "~", one would press the "~" key followed by space.

Expected Behavior

The terminal should output the diacritic character itself when the dead key is followed by a spacebar press, as per the standard input method on European keyboards. For instance, pressing "~" followed by space should result in "~".

Actual Behavior

Instead of displaying the intended diacritic character, the terminal outputs a space character " ". This behavior diverges from the norm and does not occur with other diacritics in the terminal; for example, pressing "~" followed by "a" correctly produces "ã".

The issue affects the input of all standalone diacritic characters via dead keys, impacting the standard functionality of keyboards with diacritic support.

This issue may have critical implications for command-line operations, particularly in Unix/Linux environments. A notable example is the command rm *~, which is commonly used to delete backup files created by text editors. Due to the bug, the intended command is altered to rm *, which could inadvertently lead to the deletion of all files in the directory, posing a significant risk of critical data loss.

[carlos-zamora]

Thanks for filing. Good news! This was fixed in WT Canary by #16645. We'll backport it soon.
/dup #16641

[microsoft-github-policy-service]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!