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

Add stderr output to log file. #626

Open
wants to merge 1 commit into
base: v4.2-dev
Choose a base branch
from

Conversation

DaanSelen
Copy link
Collaborator

No description provided.

@akhepcat
Copy link

@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.

@DaanSelen
Copy link
Collaborator Author

@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.

@akhepcat
Copy link

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.
STDERR is not buffered. Every character gets pushed as it comes through.

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.

@DaanSelen
Copy link
Collaborator Author

Given the buffered and unbuffered mature its also possible to not output stderr, as long as we have a standard not mixing at will

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

Successfully merging this pull request may close these issues.

2 participants