Show command on failure

[xverges]

Description

• Make failures on subcommands more informative by displaying the command that triggered them and the exit code
• Prevent potential deadlock by using exec.cmd.Output rather than sequentially reading stdout and stderr

./dapr init --container-runtime podman
⌛  Making the jump to hyperspace...
ℹ️  Container images will be pulled from Docker Hub
ℹ️  Installing runtime version 1.17.0
❌  Downloading binaries and setting up components...
❌  error running "podman run --name dapr_placement --restart always -d --entrypoint ./placement -p 50005:50005 -p 58080:8080 -p 59090:9090 docker.io/daprio/dapr:1.17.0" (exit code 126): Error: something went wrong with the request: "proxy already running\n"

Issue reference

We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.

Please reference the issue this PR will close: #1594

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation

[Copilot]

Pull request overview

This PR improves the CLI’s diagnostics when invoking external subcommands by including the triggering command (and intended exit code) in failure messages, and simplifies process execution to avoid potential stdout/stderr pipe deadlocks.

Changes:

• Refactor RunCmdAndWait to use exec.Cmd.Output() and to format richer errors that include the command string and (when available) the exit code and captured output.
• Add unit tests covering success and multiple failure modes (stderr present, stdout-only, no output).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
utils/utils.go	Reworks RunCmdAndWait execution + error formatting to surface command/output/exit code and avoid pipe read deadlocks.
utils/utils_test.go	Adds coverage for the new RunCmdAndWait behavior across success and failure scenarios.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review. Take the survey.

[acroca]

This changes a bit what ends up in the returned string because resp will now contain the stderr as well (if exit is 0), while previously we only had the stdout from the command if I'm not mistaken.
I think it's better but I'd like to hear from @dapr/maintainers-cli

[xverges]

I think that what you are describing is CombinedOutput. From https://pkg.go.dev/os/exec#Cmd.Output

Output runs the command and returns its standard output. Any returned error will usually be of type *ExitError. If c.Stderr was nil and the returned error is of type *ExitError, Output populates the Stderr field of the returned error.

FWIW, I had the same understanding as you until I checked the docs a minute ago :-)

[acroca]

Ah cool, I was wrong then. In this case, I think the behavior is the same as previously.