[Phil Sphicas (philsphicas)]

🤖 PR Validation — ️✔️ All clear

Breaking Changes	Tests
️✔️ None	️✔️ 130/130

Related command
az (all commands): stdout line endings of the Windows MSI install when invoked from bash (WSL, Git Bash)

Description
Fixes #33385.

On Windows, Python's text-mode sys.stdout converts every \n to \r\n when writing. When the Windows az is called from WSL or Git Bash, FOO=$(az ... -o tsv) therefore captures a trailing \r, and for x in $(az ... -o tsv) gives every item except the last a stray \r. That \r ends up in later az calls and causes misleading errors such as 400 Bad Request. Data that already contains \r\n is also corrupted to \r\r\n.

The cause is the stdout stream, not the tsv formatter, so this affects every -o format and commands that print() directly (e.g. az aks get-credentials --file -, --help, --version).

Changes:

• New config core.output_newline (native | lf; env var AZURE_CORE_OUTPUT_NEWLINE via the usual knack mapping).
  • lf calls stdout.reconfigure(newline='\n') in place, so text is written exactly as generated, with no conversion and no \r\r\n corruption.
  • native keeps today's behaviour.
  • An empty value means the default.
  • Invalid or unreadable values log a warning and keep native behaviour instead of failing the command.
• The MSI bash launcher (build_scripts/windows/scripts/az → CLI2\wbin\az, which WSL and Git Bash run for az) sets AZ_LAUNCHER=bash and adds it to WSLENV, so LF becomes the default for bash callers only. An explicit env var or config value always wins.
• Applied from azure/cli/__main__.py via an EVENT_CLI_PRE_EXECUTE handler: logging is configured by then and no command output has been written yet. Library use of get_default_cli().invoke() or run_az_cmd() is unaffected.

Effect:

• cmd/PowerShell: output is byte-identical unless the user opts in.
• WSL / Git Bash with the MSI install: stdout is LF-only, matching az on Linux and macOS.
• Unchanged: stderr, binary stdout writes (e.g. az storage blob download to stdout), and child processes.

Related: #33427 takes a tsv-only approach to the same issue. This change also covers json, yaml, table and direct print() output, preserves CRLF already in data, and leaves non-bash Windows callers unchanged.

Testing Guide
Unit tests (10 new in src/azure-cli-core/azure/cli/core/tests/test_output.py) cover:

• resolution order (env > global config > launcher default > native)
• empty values
• LF bytes, including CRLF already in the data
• native
• invalid and unreadable values
• streams without reconfigure

Commands run and results:

• python -m unittest azure.cli.core.tests.test_output azure.cli.core.tests.test_util: passed (48 tests). This was run with the Python bundled in the Windows MSI install (2.90.0), with this branch's src/azure-cli-core and src/azure-cli placed first on sys.path. azdev test was not run: dependency installation failed locally with a TLS error.
• flake8 --max-line-length 120 on the changed Python files: passed.
• pylint --rcfile=pylintrc src/azure-cli-core/azure/cli/core/_output.py: passed except R0903 on AzOutputProducer, which is reported for the unmodified file too.
• shellcheck build_scripts/windows/scripts/az: passed.
• End-to-end from WSL (Ubuntu 24.04) against the real MSI Python running this branch's code, through the modified launcher: 15 checks passed. Covered:
  • LF by default for json, yaml, table, tsv, --help, --version and bare az
  • AZURE_CORE_OUTPUT_NEWLINE=native (added to WSLENV) → CRLF
  • invalid value → standard WARNING:, hidden by --only-show-errors
  • existing WSLENV entries (including AZ_LAUNCHER/u)
  • no launcher → native
  • error exit code preserved

Manual check from WSL or Git Bash with an MSI install that includes this change:

x=$(az account show --query id -o tsv); printf '%q\n' "$x"     # no $'...\r'
az version --query 'join(`"\r\n"`, [`"a"`, `"b"`])' -o tsv | od -c   # a \r \n b \n  (was a \r \r \n b \r \n)
AZURE_CORE_OUTPUT_NEWLINE=native WSLENV="$WSLENV:AZURE_CORE_OUTPUT_NEWLINE" az version -o tsv | od -c  # CRLF (WSL)
az config set core.output_newline=native                         # opt out persistently

From PowerShell or cmd, output is unchanged (CRLF) unless core.output_newline=lf is set.

History Notes

[Core] az: Add core.output_newline config (native | lf) and default to LF line endings on stdout when run from WSL or Git Bash on Windows

---

This checklist is used to make sure that common guidelines for a pull request are followed.

• The PR title and description has followed the guideline in Submitting Pull Requests.

• I adhere to the Command Guidelines.

• I adhere to the Error Handling Guidelines.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[microsoft-github-policy-service]

Thank you for your contribution Phil Sphicas (@philsphicas)! We will review the pull request and get back to you soon.

[Copilot]

🟢 Approval recommended

The changes are localized, preserve native defaults for other launchers, and have focused regression coverage with no unresolved findings.

0 open findings

What changed in this PR

Adds configurable stdout line endings to prevent stray carriage returns when Windows Azure CLI output is consumed by WSL or Git Bash.

Changes:

• Adds core.output_newline with environment/config overrides and a launcher-dependent default.
• Enables LF by default through the Windows bash launcher while preserving native behavior elsewhere.
• Adds regression tests for configuration precedence, byte output, and fallback behavior.

File	Description
src/​azure-cli/​azure/​cli/​__main__.py	Registers newline handling before command execution.
src/​azure-cli-core/​azure/​cli/​core/​tests/​test_output.py	Tests newline selection and stream behavior.
src/​azure-cli-core/​azure/​cli/​core/​_output.py	Resolves configuration and reconfigures stdout.
src/​azure-cli-core/​azure/​cli/​core/​_environment.py	Defines the launcher environment-variable constant.
build_scripts/​windows/​scripts/​az	Marks bash invocation and forwards the marker through WSL.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Aditya Pujara (a0x1ab)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[x-engineering-agent]

X Engineering Agent Report

Review — Comments

Phil Sphicas (@philsphicas)

Agent review: no confirmed findings

Traced launcher defaults, config precedence and pre-execution stdout reconfiguration; byte assertions distinguish LF preservation from native CRLF translation. No actionable defect confirmed.

Windows/WSL/Git Bash execution was not independently verified; upstream CI reports 55/55 passed. The detector section below is low-confidence: its zero-production-files classification does not capture these runtime changes.

Test validation

• Agent live test: Not run; this is a review-only PR. Check author-provided test evidence and upstream CI separately.
• Regression coverage: Not applicable to the changed files.

Risk assessment — 0/100 · Low

The Low rating reflects the detected change scope with no elevated security, reliability, customer, operational, dependency, sovereign-cloud, generated-output, or cross-component signal.

• Change scope: 5 changed files, 178 changed lines (+178 / -0), including 0 production files.
• Affected components: No production component was identified.
• Risk drivers: No elevated risk signal was detected.
• Regression evidence: No production-code regression-test signal applies.
• Confidence: Low because no production changed-line evidence was available.
• Required review: No additional owning-squad review signal was detected.

Posted by x-engineering-agent (Reviewer)

[x-engineering-agent]

Phil Sphicas (@philsphicas) Ready for human review. See the X Engineering Agent Report.