Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

systemsetup outputs should be displayed on error #1333

Open
wooseopkim opened this issue Feb 12, 2025 · 0 comments
Open

systemsetup outputs should be displayed on error #1333

wooseopkim opened this issue Feb 12, 2025 · 0 comments

Comments

@wooseopkim
Copy link

wooseopkim commented Feb 12, 2025

Summary

Currently, it seems that systemsetup results are redirected into /dev/null. This leads to systemsetup error messages being entirely hidden.

Context

Personally I've had some trouble because I tried to set power.sleep.computer = 240;. That is identical to systemsetup -setComputerSleep 240, which obviously fails because The time specified must be between 0 and 180 minutes(the actual error message from the command). The activation script sets -e, and as the output gets redirected like &> /dev/null, I didn't even notice that something's gone wrong after I darwin-rebuild switched. I spent hours, days, finally figuring out what actually happened. It would be significantly helpful to other users too to let the error message displayed at least on non-zero codes.

Potential fixes

I've come up with two instant ideas.

  1. Don't redirect at all

I guess the rationale behind the redirection was not to overwhelm the user with excessive outputs. Given that, I don't think this would be the best idea, but at least it's simple, easy, and resolves the issue addressed here.

  1. Keep outputs somewhere and display them on errors

Something like:

tmp="$(mktemp)"
if ! do_something &>"${tmp}"; then
  cat "${tmp}" >&2
  exit 1
fi

This is way longer and more complex than do_something &>/dev/null. Is this the best fix? Is it good at all? I don't know. If somebody somehow fixes this, I'm more than happy to see this resolved. I'd very much appreciate if Co-authored-by would be a good fit.

Range of the issue

GitHub search currently shows me 9 files to be using the redirection. I'm not very sure how many of them should be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant