On Fri, 21 Jun 2024 11:17:34 +1000 David Gibson <david(a)gibson.dropbear.id.au> wrote:On Thu, Jun 20, 2024 at 06:15:09PM +0200, Stefano Brivio wrote:That's already the default, see pasta_start_ns(): if (!c->debug) c->quiet = 1; the problem is that if you want to debug something, and use a pasta shell (which is the most indicated way to debug something in most cases, I would say), you would usually pass --debug and a log file. Before and after this series (v5, but not v4), if you pass a log file, that debug output stays in the log file. If you don't give a log file, debug information will printed to stderr as usual. -- StefanoThe most apparent issue fixed by this series is the one from 4/6: with a log file configured, we wouldn't print to standard error anymore, during initialisation, which means that users such as libvirt lost the ability to report meaningful error messages that occurred during initialisation, in that case. v5: - in 4/8, rename the new flag once more to 'log_runtime': we don't want to log to standard error if we're running in foreground, a log file is given, and initialisation is done, otherwise debugging pasta when it spawns its own shell becomes rather impracticalAh.. right. See, I still think the semantics of always printing to stderr when foreground make more sense, but I guess I do see the point that having pasta messages appear in your pasta-spawned shell is ugly. My preferred approach for that would to keep the basic semantics that we always log to stderr when foreground, but when we're spawning a pasta shell we default to 'quiet' log level. That way if you really do want messages to stderr along with your shell/command (which I sometimes do), you can get that by using --debug or whatever.