bl-reload-gtk23: do not let xsettingsd inherit parent's file descript…

[ghost]

…ors for stdio, use devnull

When the child process spawns, xsettingsd may indefinitely keep the output file descriptor open, or write output. If it does, any redirection of output from the calling process will also apply until the child has finished writing, which can leave a shell orchestrating the redirection in a stalled state if the child never finishes writing or closes the output fd.

Minimal example: issue.

v=$(bl-reload-gtk23 2>&1)

repeatedly.

[johnraff]

The calling script hangs if a) xsettingsd is not running already and b) an attempt is made to capture the output of bl-reload-gtk23 in a variable (as in the example above).

Closing the file descriptors when launching the subprocess fixes the hang, at the cost of suppressing any stdout/stderr from xsettingsd. (Other errors from the python script, eg GTK parsing, are captured.)

Other possible workarounds in the calling script: 1) Make no attempt to capture stdout/stderr, and display them directly on the console whether running in debug mode or not. 2) Make no attempt to capture stdout/stderr, and discard them to /dev/null in every case. 3) Send the output to a temporary file bl-reload-gtk23 > tempfile 2>&1, read the file if wanted, then delete it.

None of these is ideal however...

[johnraff]

Maybe the simplest solution is to set a debug flag in the calling script (bl-obthemes in this case) and switch between options 1) & 2) above. Something like:

function reloadGTK(){ # reload gtk theme after restoring saved config
    debug "\nReloading GTK theme..."
    if [[ $dbg_flag = true ]]; then
        bl-reload-gtk23 --force && debug "\nbl-reload-gtk23: done\n" || echo "bl-reload-gtk23 failed" >&2
    else
        bl-reload-gtk23 --force >/dev/null 2>&1 || echo "bl-reload-gtk23 failed" >&2 
    fi
}

xsettingsd's output seems a bit unpredictable, but the whole thing's a somewhat minor issue to spend a lot of effort on.

[johnraff]

xsettingsd's output seems a bit unpredictable

This is because its redirections are set at the time it's launched, and apply from then on, regardless of any redirections applied to the calling script.

[johnraff]

For now, applied above workaround so the package can be upgraded and the refreshed iso release can go out.