-
Simon McVittie authored
If users of an X11 environment restart it inside a terminal emulator, and then close the terminal emulator (which seems to be a somewhat popular meme on various forums), we can end up with stdout/stderr pointing to a pseudo-terminal that is no longer associated with a terminal emulator. All writes to such a terminal fail, and when we're running under `set -e`, that will terminate the script. Worse, we can't even diagnose what has happened, because any error messages we might have shown are also going into the void. Mitigate this by ignoring `set -e` when logging diagnostic messages, analogous to the behaviour of `g_warning()` and similar C API calls. (After all, what would we do about it - log a diagnostic message?) Related to <https://github.com/ValveSoftware/steam-for-linux/issues/8069 >. Signed-off-by:
Simon McVittie <smcv@collabora.com>
Simon McVittie authoredIf users of an X11 environment restart it inside a terminal emulator, and then close the terminal emulator (which seems to be a somewhat popular meme on various forums), we can end up with stdout/stderr pointing to a pseudo-terminal that is no longer associated with a terminal emulator. All writes to such a terminal fail, and when we're running under `set -e`, that will terminate the script. Worse, we can't even diagnose what has happened, because any error messages we might have shown are also going into the void. Mitigate this by ignoring `set -e` when logging diagnostic messages, analogous to the behaviour of `g_warning()` and similar C API calls. (After all, what would we do about it - log a diagnostic message?) Related to <https://github.com/ValveSoftware/steam-for-linux/issues/8069 >. Signed-off-by:
Simon McVittie <smcv@collabora.com>