-
-
Notifications
You must be signed in to change notification settings - Fork 294
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
Add stderr output to log file. #626
base: v4.2-dev
Are you sure you want to change the base?
Conversation
@donaldzou - i think this is a good long-term step for the holistic view, but in addressing it, it highlights a missing aspect of the installer and its subtasks: If you pass STDERR (pre PR) then the user is aware of any background process errors as they occur. By capturing STDERR to the install log (post-PR) the user is no longer aware of any background errors, and won't know that any need to be resolved. Having the errors inlined with the other installation context is very useful, but I'm not sure how to capture "something wrote to STDERR, set a flag" here, so that we can alert the user appropriately to check the logs. |
Any suggestions are welcome. I was scrolling through the script and made it standard to redirect all output to the install.txt file. |
Spent a bit of time thinking about this, and playing with different approaches. There's a few issues at play, and one of them is just the POSIX layer for STDOUT vs STDERR STDOUT is line-buffered. So nothing (typically) gets flushed out until that newline is sent. So the first challenge is reading both STDERR in a buffered manner, but then also interleaving it with the STDOUT messaging so that you don't lose contextual clues. This is impossible in pure bash, presumably in all shells, because of that POSIX requirement. it's possible to do some of this with another utility that captures the STDOUT and STDERR of a running program, but that presents additional challenges for portability and ease-of-use. And it still doesn't solve the desire to capture that error status back upstream into the script. But that's just all presupposing using the existing code structure - it might be possible to tease things apart by refactoring those problematic sections where we want errors to bubble up mid-pipeline and capture them. |
Given the buffered and unbuffered mature its also possible to not output stderr, as long as we have a standard not mixing at will |
No description provided.