Comment by anyfoo

14 hours ago

Does no one know what exit codes and stderr vs. stdout is anymore?

I work with old and new code bases used by many clients in complicated setups, but adding a warning to stderr while stdout was left untouched, and proper exit codes maintained, was hardly, if ever, a problem so far.

Of course, there's always some unpleasant exception, but it's rare.

And of course, I also understand that the author might have found themselves not only in one of those rare-ish instances, but also one where reasoning with the other side was fruitless.

> Does no one know what exit codes and stderr vs. stdout is anymore?

Sounds like you don't use ffmpeg very often. Because ffmpeg is able to send its output to stdout to be piped to other apps, verbose text output can't use stdout as one would expect. Non-error text is sent to stderr instead. So when you want to trap the text output you have to route stderr to text file. It takes some getting used to, but it's now normal for me.

So, yeah, I know stderr vs stdout still, but it's not what you want it to simply be. In the real world, things are not as clean as they are in school books.

  • That is exactly what I expect, or did I misread you? I expect its text output on stderr, and stdout being reserved for its video (or whatever) output.

    Maybe the name “stderr” is a bit misleading. It’s totally common for non-error output to be in stderr as well, like verbose/debug logging.

  • I've just checked the man page for ffmpeg and they have a `-report` flag to capture the log. There should be no need to redirect stderr.

I worked on a code base that ran on a variety of Unixes. One customer complained about file corruption from our software. Turns out that their Unix setup was... rather unique. Spawned programs were not given a stderr file handle! If you wrote to stderr, it scribbled on whatever file was open on file handle 2.

We, uh, reasoned with the other side - we told them to fix their stupid broken setup.

  • Glad you were able to sort it out properly. I guess maybe I'm also lucky to much less rarely work with, shall we say, consultation-resistant engineers than discussion forums sometimes make you believe.