Executing certain X applications causes '(null)' to be printed on screen

[andreas--e]

Hi, just found a bug in latest conky, which probably was there in previous versions as well.

Here's my .conkyrc, stripped down to the max:

double_buffer yes own_window yes own_window_class Conky own_window_hints undecorated,sticky # ,skip_taskbar own_window_transparent yes

background yes total_run_times 0

use_xft yes xftfont Bitstream Vera Sans:size=7 xftalpha 0.85 override_utf8_locale yes

minimum_size 150 maximum_width 480

border_width 1

uppercase no

TEXT \ ${texeci 6000 /usr/bin/xclock} \ --other conky stuff goes here---

And it's not the interval that causes this. Happens with 600, 6k and 60k likewise. xclock itself executes very well in threaded mode and (unlike with $pre_exec, $exec, $execi, $execp) it will not block conky from appearing.

Just this '(null)' is a bit disturbing, to put it mildly. Wish I knew what triggers this, and why. Surely it is not any kind of stderr output (tried 2>/dev/null to no avail).

[Tucos]

2014-09-18 22:03 GMT+02:00 andreas--e notifications@github.com:

xclock itself executes very well and (unlike with $pre_exec, $exec, $execi, $execp) will not block conky from appearing. Just this '(null)' is a bit disturbing, to put it mildly. Wish I knew what triggers this, and why.

$exec and friends are meant to be used when one wants the output of a command in conky. The reason all but $texeci block conky is because xclock does not exit. $texeci runs it in a separate thread whenever the interval expires and output is read when it is available (each update_interval the old output is displayed).

The '(null)' you get is because that's what printf(3) shows when a null pointer-to-char is printed with %s. The string is null because xclock has no output at all and thus fread in the thread blocks until xclock exits (which is when conky exits). It's nothing to worry about as such, but you cannot get rid of it either (and that is not a bug).

[andreas--e]

$execi, $execp) will not block conky from appearing. But it did here. Conky was launched, but not shown. Not until I pkill'ed xclock, Conky showed up as normal. Going to threaded launching was the only reasonable way out.

And no matter if it's deemed a bug or not: the problem is I will always have to launch conky per mini-script which launches xclock plus conky underneath. Since that (null) is very prominent and simply disturbs the view... Unlike there is another trick that can be used. As I said, surprisingly not any of the known 1>/dev/null 2>/dev/null ... tricks worked here, in no direction.

[lasers]

3 years 11 month passed. Can you determine if you're still having this problem today on 1.10.8 or preferably 1.10.9_pre (git)? Thank you.

[lasers]

Hi. I tested the config above. For historical purposes, here's the new syntax config.

conky.config = {
    out_to_x=yes,   -- custom
    out_to_console=yes, -- custom
    double_buffer=yes,
    own_window=yes,
    own_window_class=Conky,
    own_window_hints='undecorated,sticky',
    own_window_transparent=yes,
    background=yes,
    total_run_times=0,
    use_xft=yes,
    xftfont='Bitstream Vera Sans:size=7',
    xftalpha=0.85,
    override_utf8_locale=yes,
    minimum_size=150,
    maximum_width=480,
    border_width=1,
    uppercase=no,
}
conky.text = [[
    ${uptime}
    ${uptime_short}
    ${user_names}
    ${processes}
    ${texeci 10 /usr/bin/xclock}
]]

I did not see any (null) on the screen nor in the console. I don't view this as a bug either and I think that users shouldn't add X11 apps directly in the config. It should fare better if we put them in scripts instead where it can decide what to do if the process is still running, to return empty or custom strings, and more.

3 years 11 months ago passed too and a lot has changed as Conky went through a major rewritten and several iterations already so I'm going ahead with closing this stale issue. Thank you. :-)