mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3749] Where to print debug messages (stdout or stderr)? #2365
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2365
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @smitsohu on GitHub (Nov 13, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3749
While the vast majority of Firejail's debug messages currently go to
stdout, occasionally they are printed tostderras well. I'm curious if there is desire to have a uniform behavior (one way or the other).Background: When attempting a fix for #2301 I ran into the problem that I cannot print messages to
stdoutfor a short period of time (otherwise Firejail would mix debug info and file content).@ghost commented on GitHub (Nov 13, 2020):
No personal desire in this context, besides avoiding such a mix obviously...
@rusty-snake commented on GitHub (Nov 13, 2020):
Related: #3354
@smitsohu commented on GitHub (Nov 14, 2020):
Personally no strong opinion either.
But having two different output destinations is somewhat inconvenient and error prone, as users might capture debug output by redirecting it to a file, potentially missing the important messages that are still going to
stderr.@ghost commented on GitHub (Nov 14, 2020):
@smitsohu That's indeed a very good point. I think I saw that kind of behaviour in the past and redirected both stdout and stderr to a file to avoid missing important info. Not sure if we can improve things in that regard.