dump truncated and stdout permanently broken on non-blocking fd

[vxpyy9]

When stdout is in non-blocking mode, the first large output written via std::cout is silently truncated and all subsequent output is suppressed for the rest of the session - std::cout ends up permanently in an error state.

• first dump after connecting (any format, any datastore) prints, but is cut off in the middle
• after that, every command produces no output - commands run, nothing appears

Proposed fix
Don't rely on std::cout for output on a possibly non-blocking fd. Route output through a helper that writes to the fd in bounded chunks, retrying on EINTR and EAGAIN/EWOULDBLOCK (via poll).

I'd like to fix this upstream, but since it touches output across the whole app, I'd rather check how you'd prefer to handle it before opening a PR: whether to replace each std::cout call individually, route all output through a single wrapper, or something else entirely. Thanks!

[jktjkt]

How do you end up with a non-blocking stdout? Are you perhaps launching netconf-cli from some external system and trying to parse its output? Why do you need the stdout to be non-blocking?

[vxpyy9]

We're running netconf-cli interactively over an SSH session, and the pty for that session has O_NONBLOCK set, so stdout is non-blocking too. We don't set it or need it, it just comes from the environment

[jktjkt]

How do I reproduce this, or how exactly do you launch it? A simple echo dump json | ssh host.example.org sysrepo-cli > x.json appears to work fine here.

We never thought about what happens when the stdout FD is non-blocking, and a you say, the STL is not designed to support that. We could either:

1. do nothing,
2. detect this, and fail if it's non-blocking,
3. detect this, and set it to blocking unconditionally,
4. try to refactor our IO so that it works with non-blocking stdout.

I'm not a big fan of 4) because I do not understand why it is worth the effort. Would 3) work in your env? But before we do anything, I would really prefer to understand how exactly you end up in a situation like this in the first place.