I was asked to clarify the question. I'm not asking about any specific program's behavior, but I used ffmpeg as an example of the behavior I'm asking about. To restate the question:
When a program's
stdout is piped to another program, how does that program also produce terminal output. Is
stderr the only option in terms of output streams?
I'm a long-time Windows developer slowly learning my way around Linux to support various electronics and programming hobbies. I'm working with some headless Raspberry Pi's, so I only interact with them through an ssh terminal. I had thought terminal output was just
stdout, and indeed when I control a child process launched from a .NET Core program via the
Process class, the terminal output is what my program receives when it intercepts the
But I need to launch bash so that I can pipe ffmpeg to VLC, and I realized when I do this from the terminal "by hand", ffmpeg writes processing details to the terminal while simultaneously piping data to VLC. I had thought a command-line pipe redirects
stdout to another program's
I was having trouble with bash (it doesn't seem to pass
stdin data from my program to the programs launched with the
bash -c "ffmpeg ... | cvlc ..." switch), so I was considering using two
Process instances and handling the pipe that way.
Then it occurred to me to wonder about the relationship of terminal output versus pipe output, and what's really going on behind the scenes.
Edit: When I wrote that, I forgot that I typically capture and output both
stderr using the
Process class. Under Windows,
stderr is rarely used in my experience, is it perhaps routine in Unix to use
stderr for non-error terminal output? Just a guess...
stderr, but I can't really tell since your mention of ffmpeg and vlc is clouding the waters. Could you please edit and simplify this to one, specific question?