In particular:
- Don't call get_battery_perct() recursively.
- Use define for length of string holding battery name.
- We can use strcpy() since bat is zero-terminated.
Currently we set inotify_fd to the value 0 when inotify_fd hasn't been
created yet, or after we close it. But 0 is a valid fd, and we check
for the value -1 to see if it's been initialized. So, if inotify
support is compiled in, but we disable_auto_reload, we can end up
closing fd 0. This can screw up various other things in weird ways,
including that exec'd processes appear to have an invalid stdin.
So, set inotify_fd to -1 to clear all of this up.
luamm is now able to be compiled with both lua 5.1 and 5.2 (assuming 5.2 has backward
compatibility features compiled in). It is my intention to always support at least two versions
of lua.
On systems, the buildprocess will complain:
[ 7%] Building CXX object src/CMakeFiles/conky.dir/c++wrap.cc.o
conky/src/c++wrap.cc: In function ‘std::string strerror_r(int)’:
conky/src/c++wrap.cc:66:37: warning: ignoring return value of ‘char* strerror_r(int, char*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
According to "man 3 strerror_r" the buffer used as 2nd arg is not always used, this patch also fixes that problem.
On systems with a strict compiler, the buildprocess will complain:
[ 70%] Building CXX object src/CMakeFiles/conky.dir/update-cb.cc.o
conky/src/update-cb.cc: In member function ‘void conky::priv::callback_base::stop()’:
conky/src/update-cb.cc:49:34: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result
This patch fixes this warning (and by doing this also checks if the write worked)
Before, in the case of an unknown battery status (which often happens on my Sony VAIO laptop after waking from sleep), the buffer would be unterminated.
(Although, this memmove trick is a bit odd. It would probably be better to remove the memmove's and put a single buffer[1] = '\0'; at the end of the function).
Conky takes process names from /proc/<pid>/stat and it's limited to 16
chars in kernel. That obviously makes top_name_width option to work only
for decreasing name length. To obtain longer names we parse
/proc/<pid>/cmdline.
Not every process has cmdline, so we take both process names and choose
one we want to use. Like this:
- Get process name from /proc/<pid>/stat
- Get process cmdline from /proc/<pid>/cmdline
- Transform cmdline to a bit simpler form(i.e. "/usr/bin/python
/usr/bin/terminator" to "python /usr/bin/terminator"), keeping
the arguments(might be changed easily)
- Choose the one that is longer and use it
== common.cc ==
'result' can be uninitialized.
== conky.cc ==
strcpy()'s overlap: undefined behaviour. memmove()'s one is
defined.
== eve.cc ==
Some simplifications, and there are two leaks:
1. 'mySkill' could be leaked. So, let's make 'skill' point to it instead
of strdup()'ing the buffer.
2. 'output' could be leaked at l.390.
== freebsd.cc ==
Leak of 'freq_sysctl'.
== net_stat.cc ==
free() already null-checks, so we don't need to do it again.
== proc.cc ==
Leak.
Signed-off-by: Pavel Labath <pavelo@centrum.sk>
Sometimes wlan related TEXT causes segment fault, and backtrace shows it's strtok in
iw_get_stats.
I read the code of wireless_tools, which says 'strtok not thread safe, not used in WE-12 and
later' for iw_get_stats. But it need to first check if has_range and then we_version_compiled.
In conky/src/linux.cc, iw_get_stats is called before iw_get_range_info, hence has_range is always
0 in iw_get_stats and strtok is used. I simply move iw_get_range_info before iw_get_stats and no
segfault up to now.
patch by ruikai
curl implements some of the timeouts using alarm(), where the alarm handler longjmp()s back into the
curl code. This is a bad idea in multi-threaded applications, since it is not guaranteed that
SIGALARM will be recieved by the correct thread. Therefore, we instruct curl to avoid using
signals.
Conflicts:
src/ccurl_thread.c
Adds mpd_albumartist support as an object since mpd_artist lists all participating artists of the
current song and not the main album artist.
patch by Sébastien Lavoie-Courchesne
statfs64 ist atm linux specific; wrap statfs around it.
Also cleanup param.h and mount.h including: the assumption in fs.cc
that their presence is a sign of *BSDs is wrong, as they exist in
linux too with different meaning.
Besides presence of mount.h isn't detected in Conky.cmake, so
conditional including mount.h in fs.cc is useless. Is just works
because mount.h and param.h are included in freebsd.h and dragonfly.h
later on. They are unneded in linux.
Just remove conditional including of mount.h and param.h in fs.cc,
conditional wrap statfs64 in proper *BSD header files.
* process* management left to top.cc
* compile with -Wall -Werror (lots of wasted time for stupid errors)
* unify find_process() and new_process(), as used always together
Signed-off-by: Pavel Labath <pavelo@centrum.sk>
* don't use kvm_* calls, just sysctl (so no suid perm necessary)
* sysctls calls in general aren't thread safe, collapse callbacks
using same sysctls (specifically total/running procs and proc list
ones).
Some sysctls need two calls (first to get size of obj returned,
second to get object self); if different threads use this schema
on same sysctl, weird values are returned (first/second calls
sequence should be serialized).
In general it makes not much sense too having more threads that use
the same sysctl; just get info once and populate all data.
* add DragonFly specific extended uname string ($version in conky.conf)
with git version and signature
Todo:
- top process list logic is old style, use top.cc funcs.
- find a solution for cpu freq
Signed-off-by: Pavel Labath <pavelo@centrum.sk>
also change a magic constant in net_stat.h to reflect the fact that it depends on
MAX_NET_INTERFACES. For more info, see sf.net #2872682 and gentoo bug #384505
ps: this should really be solved in a more need way, without the need for static arrays
apparently, this was actually a feature as someone made it deliberately act that way. However, I
agree with the bug reporter that it is strange so I remove it.
Currently the variables related to xmms2 in conky do not update if the currently playing track
has any of its information updated (ie: the title changes). This results in incorrect behaviour
for streams where the same track is continually played but the title and artist change as new
songs are played. The attached patch corrects this issue by changing conky to respond to a
callback that fires when xmms2 media library entries are updated. After the callback fires, the
patch checks to see if the media library entry that changed corresponds to the currently playing
song and if it does updates the conky xmms2 related variables accordingly.
A different version of the patch was previously submitted and accepted into conky. Unfortunately,
this patch contained a bug that caused conky xmms2 variables to be updated when any media library
information was updated. However, the previous patch was reverted as a result of a commit the
made conky compatible with a new version of the xmms2 client api.
Patch submitted by Tamim Khan.
Signed-off-by: Pavel Labath <pavelo@centrum.sk>
this sort of fixes sf.net #3306538. The person there correctly tested for the existance of the
file with $if_existing, but the problem is we run the callbacks regardless of the conditional
tests.
Noone knows what it was supposed to do and removing it seems to fix sf.net #3411610 (and probably
a few others). If it turns out it was doing something useful, we will try to reintroduce it
without breaking other things.
The problem was that the callback thread is destroyed only in the destructor of the callback_base
class (which is called after the destructor of the derived classes). This means that the thread
is running even when it's object is partly destroyed, which can cause segfaults, race conditions
and other nasty problems.
I've fixed it so that the thread is destroyed before the underlying object's destructor is
called.
I revert this, because it breaks padding for numbers < 1000, which causes ugly text shifts when
numbers change from <1000 to >1000. If someone disagrees with this, we can talk about it in
#conky. I asked before doing this, but noone seemed to care.
This "fixes" bug #3389641 on sf.net, reported by sakalisc.
This reverts commit c9cf08d9e9.
Conflicts:
src/conky.cc
when the system clock is moved backwards, the update interval would be calculated incorrectly. If
it was moved back far enough, conky would use 100% cpu. Conky now uses monotonic clock to prevent
this. If it turns out to be unsupported on some platform, an appropriate fallback can be added.
problem reported by norsetto
conky now sends the password using the length + string format, which should not need any quoting
of special characters. Hopefully, we won't find a server which does not support this encoding.
This also fixes a bug which prevented the password from being entered from the console.
bug reported by Brent
In the current implementation of xmms2_smart, when a song being played does not have an artist
name (as is the case with many streams) conky displays an empty space a dash followed by the
title (ex: " - Song Title"). The following patch improves this by only displaying the song title
in xmms2_smart when the song artist is empty. Moreover, the patch also fixes an issue that
existed with the previous xmms2_smart which seemed to be checking the string length of the song
title twice before outputing the url of the song. This seems like a typo and what this line
likely meant to do was check that both the song artist and song title were empty before
displaying the song url.
Patch contributed by Tamim Khan.
Signed-off-by: Pavel Labath <pavelo@centrum.sk>
