Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
sw-notify-send -- a system-wide notify-send wrapper =================================================== Please note that this project is no longer maintained. Please use libtinynotify-systemwide & tinynotify-send instead. A quick introduction -------------------- Even wondered why libnotify doesn't support sending notifications using user other than the one running the notification daemon? I have done that many times too, and never found an answer. This is why I have created this tiny tool. sw-notify-send stands for 'system-wide notify-send', and that means it is a wrapper for the `notify-send` tool, allowing to use it using another user account (and send notifications out of the particular session running the daemon). System requirements ------------------- * The `proc` library (which can be found in the procps package), * [libtinynotify] with `--enable-cli`. :https://github.com/mgorny/libtinynotify/ How to use ---------- sw-notify-send is only a dumb wrapper for notify-send. Thus, it doesn't take any arguments of its' own and passes all of them to notify-send. Thus, to use it you simply replace `tinynotify-send` with `sw-notify-send` in your shell script (or command line, or wherever you're going to use it). In other words, you use it like: sw-notify-send 'Test' 'Hello world!' Simple, isn't it? And as you might have expected, sw-notify-send requires a lot of privileges (details below). Thus, if run using a regular user, it will most certainly notice only his own notification daemon. To get real system-wide notifications, you need to run sw-notify-send using the superuser account (e.g. through sudo). Technical details ----------------- sw-notify-send simply iterates over all running processes (using the `/proc` filesystem) looking for anything looking like a DBus session bus. And by 'looking like', I mean having `dbus-daemon` as the basename and `--session` among its arguments. For every one it finds, it tries to grab the access details and send the notification. It tries to preserve DISPLAY and XAUTHORITY, and calls `setresuid()` to get the identity of that user -- and that should be enough for dbus to let us in. In addition to that, sw-notify-send also supports having the notification daemon running in a chroot. If it founds one doing so (looking at the `root` procfs entry), it calls `chroot()` to enter the chroot. <!-- vim:se syn=markdown : -->