Description
Is your feature request related to a problem? Please describe.
Uncontrolled logging to stderr produces logs that may be hard to read, or even garbled when the progress bar is active.
Describe the solution you'd like
For interactive child processes, we stop the progress bar and do not capture stderr; just forward our own stderr fd.
For non-interactive child processes, the fix is not entirely trivial, because of competing requirements:
- streaming stderr will show relevant logs during long-running or non-terminating operations
- hiding the log and showing the whole output in an exception message makes the output easier to read, especially of there's more logging on screen that's not related to the problem.
Both behaviors are desirable and can be combined:
- hide and capture the log to a buffer for the first 10 seconds. If the command terminates, we can use or throw away the buffer.
- if 10 seconds pass without terminating, forward the buffer contents to stderr, perhaps with a line prefix to show context
- similarly forward new logs in a streaming fashion, while also saving it to memory for use in exceptions.
Describe alternatives you've considered
Additional context
We call processes such as version control systems.
Whether a process is interactive may not always be obvious, and needs to be decided on a case by case basis for each child process. However, if stdin is not a tty, nothing is interactive.
Priorities
Add 👍 to issues you find important.
Activity