Firejail: Make firejail print to stderr by default (instead of stdout)

[vn971]

Steps to reproduce:

• firejail --noprofile true 1>stdout 2>stderr

Expected: file "stdout" is empty, file "stderr" contains firejail information (Parent pid 4688, child pid 4689 etc)

Actually: file "stdout" contains the info, "stderr" is empty.

Printing additional non-necessary information to stderr by default is a common nice thing in many Linux programs, I suggest to embrace it.
Thoughts?

[Hocuri]

Do you want to separate Firejail's information (Parent pid 4688, child pid 4689 etc) from the sandboxed process' stdout? Maybe there could be an option to toggle this extra information off and just print errors and warnings to stderr.
The disadvantage of stderr is: As far as I know it is assumed that the message is urgent and it is printed without buffering, although I do not know how bad this is on modern computers.

[vn971]

@Hocceruser what would be the problem to print 2 lines without buffering?

Currently, firejail has the --quiet option, which will remove such info. (Example use case for --quiet is when firejail-ed program output is fed to another tool.) Writing to stderr would fix most usages of --quiet as a bonus.

[Hocuri]

Currently, firejail has the --quiet option

Ah yes, I did not see this, sorry.

When I run firejai firefox it is about 10 lines output (6 Reading profile... lines plus 4 lines of other info) but I still do not know if this is a problem.

Would there be any advantage of stderr over stdout apart from not having to write --quiet?

[vn971]

@Hocceruser yes, as I wrote in the issue description.. It's the standard approach to logging/printing on Linux. It allows firejail-ed program output to be used by other tools, while still not discarging the information.
Just see how all other programs print their "logs" as well as their "primary output".

[reinerh]

Isn't stderr supposed to be used for errors? And stdout for normal informational output?

[Ferroin]

@reinerh It really depends on what you are talking about. If you're designing a program that's supposed to only be used interactively and will never be involved in a shell pipeline, then yes that's the standard practice. The moment you start talking about non-interactive or pipeline usage though, the standard becomes printing everything except actual program output on stderr (note that in this case, logged messages _are not_ actual program output), and once you're talking about a wrapper program like firejail (or more concretely looking at existing examples, like parallel, socksify, datefudge, fakeroot, and similar), _everything_ that isn't from the wrapped program has to go to stderr so that you don't interfere with the output of the wrapped program.

@Hocceruser I'm pretty sure there's no such 'rule' about having no buffering on stderr (at least, if there is, it's not part of the ANSI C standard, and I'm pretty sure it's not part of C89 or C99 either). The only practical difference lies in handling of redirection in the shell (you can more easily redirect stdout than stderr, and stdout is what gets captured to be sent to the next stage in a pipeline). The whole original point was to segregate output being sent to another program with informational output, but back then informational output only meant errors, thus the usage of the name 'stderr'.

[startx2017]

everything that isn't from the wrapped program has to go to stderr so that you don't interfere with the output of the wrapped program.

I've replaced all related printf calls with a fmessage() function call (implemented in util.c) and from there we can send all of them to stdout or stderr. I would go for stderr, @Ferroin makes a good point.

commit: https://github.com/netblue30/firejail/commit/c59a19848dd37ac12bf024ba0cc295d3338116ae

[netblue30]

Let's keep it as stderr, thanks @startx2017