Subprocesses using bare `\r` for in-place terminal progress updates (e.g. `Downloading 50%\rDownloading 100%\n`) pass those carriage returns through `_PipeReaderThread._write()` unchanged. When the output stream is not a terminal (file redirect, pipe), the `\r` chars survive into the written text, producing `^M`-riddled output. ## Changes - **`craft_cli/messages.py`** — Normalize carriage returns in `_PipeReaderThread._write()` before line-splitting via a single `re.sub` pass: - `\r\n` / `\r+\n` (Windows endings, `\r\r\n`) → `\n` (no extra blank lines) - bare `\r` (in-place overwrites) → `\n`, so each update becomes its own line - `b"\r" in data` guard skips regex entirely for the common CR-free case - **`tests/unit/test_messages_stream_cm.py`** — Two new tests as reproducers: - `test_pipereader_carriage_returns`: `b"Step 1\rStep 2\rStep 3\n"` → three clean lines, no `\r` - `test_pipereader_windows_line_endings`: `b"line1\r\nline2\r\n"` → two clean lines, no `\r` ```python # Before: \r passed through to the captured message # text == ':: Initializing\rDone!' ← stray ^M in file # After: bare \r treated as line separator # text[0] == ':: Initializing' # text[1] == ':: Done!' ```