I think that, if I were doing this, I would want to do it very explicitly, to avoid side-effects.   In other words, I would design my app in such a way that there is a universally-available (to the app...) object which has a method to generate output.   The entire application uses that method.   Unbeknownst to it, that method writes the output by some means to a temporary file.   Then, when the app is ready to deliver that output to the end-user, a final bit of code slurps that file and pumps it to STDOUT.

What I am very-deliberately doing in this case is trying to build in flexibility and “future-proofing.”   There is probably not one thing that is more pervasive, in any application built for any environment and for any purpose, than “how that application generates and delivers its output.” Therefore, if when changes occur down the line, a change to this aspect of the system would be “a highly pervasive (HIPER) change,” as IBM used to say.   Nothing is more de-stabilizing, both to the app and to your receding hairline and what’s left of your social life, than, “a HIPER change to a deployed production system.”   Do everything that you reasonably can to prepare for it, as early as you can in the design-and-build process.