> So what you mean to say is that the problem is not so much that there isn't any error reporting, but that, in C, it's being ignored ?

...huh? No, I'm not saying that. I'm saying that if you write a shell script there's a risk of not detecting errors that you care about. I also said that I like to rewrite these overgrown shell scripts in Go, which is apparently a Wrong Opinion and some bad C code will somehow convince me of this.

First, the nitpicks: EAGAIN should not be handled here. EAGAIN shouldn't be retried in a loop, that will just spin the CPU for no good reason. If printf() returns EAGAIN it means that you made stdout non-blocking and hopefully you would know if you did that, but that's unusual except in language runtimes. There's also a missing break; in the switch.

Beyond that, I don't really care about error handling for printf() when I'm logging output or running interactive programs.

Compare this with the behavior for C++:

    #include <fcntl.h>
    #include <iostream>
    #include <unistd.h>
    int main() {
        close(STDOUT_FILENO);
        std::cout << "Hello, world!\n";
        return 0;
    }

Try it yourself.

As an example of the errors we see in our logs, they often look like this:

    some_file.go:399: could not realign warp core coupling b502:
      plasmaManifold.PhaseInterplex(): host not found: m19d.eng.ncc1701d

The "ignored errors in the Go standard library" aren't really ignored errors. Look at the bufio code a little bit more closely, you'll see that those errors are properly returned.