error handling on stdout - pipe buffer

[patrykcieszkowski]

Pipe buffer was delaying progress updates, and on some commands - prevented them from appearing at all. I ended up using script cmd to disable it, but it merges stdout and stderr outputs together. We have to either find a better solution or to somehow distinguish between the desired output and the error.

[patrykcieszkowski]

We could print errors to a log file, and read them directly from the file. This would stop errors from appearing in stdout.

ping -4 -c 3 -i 0.2 -w 15 -n br.debian.org 2>/tmp/errorlog

Of course, every measurement would need to have its own errorlog file.

Alternativelly, we could attach a prefix to stderr and distinguish errors from the actual output that way:

ping -4 -c 3 -i 0.2 -w 15 -n br.debian.org 2> >(sed 's/^/error: /')

[patrykcieszkowski]

Here's what I found, and I actually don't understand why that is:

If from within stdout handler, you call cmd.stderr?.emit('error', data), the execa is going to fail and will report an error. However, the error won't be reported under stderr value, but under stdout.

[patrykcieszkowski]

Alternativelly, we could attach a prefix to stderr and distinguish errors from the actual output that way:

As it turns out, when modifying stderr input, the result is not always present. It's especially noticible if you run test on multuple probes at once. I don't know why.

[patrykcieszkowski]

going back to unbuffer seems like the only solution; it captures the exit code, which makes errors resolve as usual.

[jimaek]

Ok well let's do it then. Better now than after going live

[patrykcieszkowski]

mtr always ends with exit code 0 when requested with non-UI output type. Seems like we gonna have to rely on manual handling at some cases.

traviscross/mtr#294

[github-actions]

🎉 This issue has been resolved in version 0.7.4 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀