[Konsole-devel] [Bug 297224] Command-line options ignored when stdout redirected to /dev/null

[Rogier]

https://bugs.kde.org/show_bug.cgi?id=297224

--- Comment #2 from Rogier <rogier777 at gmail.com> ---
Thanks for the reply.

> The situation is improved a bit in KDE SC 4.8.0, where stdin is checked instead of stdout. That is still naive. The current development branch performs that check by trying to open /dev/tty. Maybe that change should be backported into the 4.8.x branch.

Personally, I don't mind waiting until 4.9 (?).
I also suppose you'd rather spend your time fixing new bugs, or implementing
new features than backporting fixes...

The way I understand your explanation, one of my observations is not explained:
    session-on-display 0 $ konsole --display 1:0
new konsole session opens on display 1:0
    session-on-display 1 $ konsole
another new konsole session opens on display 1:0, as expected
    session-on-display 1 $ konsole > /dev/null
a new konsole session opens on display 0, whereas it is obviously expected on
display 1.

The way I interpret this, is that the last konsole invocation creates a new
window using an existing konsole process, as is to be expected. However, it
obviously selects the incorrect process: the invoking process is running on
display :1.0. Konsole however, still selects the konsole process on display
:0.0 to create the new window.
IMO, a freshly started konsole should open a window on the current display.
Even if that display does not already have a konsole process.

As this behavior is not seen when konsole is started from an rsh session, I did
some more testing, and it appears that the environment variable
DBUS_SESSION_BUS_ADDRESS is 'the culprit' - clearing it causes the new konsole
window to open on the correct display. Apparently DBUS_SESSION_BUS_ADDRESS
(still) contains the address associated with display :0.0, even though konsole
is running on :1.0, and konsole is using that address regardless of the display
it is running on.

Kind regards,

Rogier.

-- 
You are receiving this mail because:
You are the assignee for the bug.