3 ms·
Just line buffer what you read from stdout/stderr. Or even display them in separate sections in your UI. There's no guarantee of ordering between stdout/stderr
by catern 8y ago
Just line buffer what you read from stdout/stderr. Or even display them in separate sections in your UI.
There's no guarantee of ordering between stdout/stderr, so line buffering them, or displaying them in separate UI sections, or even doing some non-blocking reading to flush one fully before flushing the other, should be sufficient.
- amasad 8y ago> Or even display them in separate sections in your UI. That's a non-starter. We think barring a great UX improvement, the environment should look as predictable and as close to a local setup as possible.
- catern 8y agoThen line buffer stdout and stderr to the same UI element, and also provide an option to toggle showing just one or the other. Sounds pretty useful to be able to switch between just showing one or the other, and showing them line-interleaved by timestamp, even if you do want to default to the latter. If line buffering isn't enough, you can use heuristics around read sizes and non-blocking reading to guess whether a given write to the pipe was intended to be done as a block.
- zAy0LfpBZLC8mAC 8y ago> There's no guarantee of ordering between stdout/stderr There absolutely is. If the two file descriptors refer to the same open file description or the same pipe/socket/character device, then the ordering of write syscalls is preserved--and that is the default for terminals.