Parsing enviroment variables of a process at a BSD-like operating system

Stephan Haller nomad at froevel.de
Mon Jul 6 06:31:02 CEST 2015


Thanks a lot for your immediate help :) Although it looks harder than
expected. But it may look hard because I have no experience with BSD.
Ok, let's see what I can do with it.

I also see that I confused you so I would like try to explain my idea a
little bit more precisely. The problem is not if an application is
running but which one is running. I need the desktop ID or at least the
corresponding '*.desktop' file used to launch the application. If a new
window is opened I can retrieve the process ID which owns window and i
realized that the best match is found when parsing the enviroment
variable set of the process and looking up GIO_LAUNCHED_DESKTOP_FILE and
GIO_LAUNCHED_DESKTOP_FILE_PID whereby GIO_LAUNCHED_DESKTOP_FILE_PID has
to match the process ID to ensure the variables really belongs to this
process and are not inherited from a parent process. The variable
GIO_LAUNCHED_DESKTOP_FILE contains the corresponding '*.desktop' file
what I look for. That's why I want to parse the enviroment variables of
a process. It is very accurate in its result as long as nobody fakes the
environment variables forcibly.

I'm open for other ideas ;)

But there is also another algorithm to determine which application is
running when parsing the enviroment variables failed. I get some
properties from the newly opened window (class group name, instance name
etc.). Then I add '.desktop' to these values and try to lookup a
matching application in the application database I manage - first with
unmodified value and then in all lower-case. This should be portable to
all operating systems but I might miss applications.

Again: Thanks :)

Regards,
Stephan

Am Sonntag, den 05.07.2015, 23:31 +0200 schrieb Guido Berhoerster:
> * Landry Breuil <landry.breuil at gmail.com> [2015-07-05 22:31]:
> > On Sun, Jul 5, 2015 at 9:36 PM, Stephan Haller <nomad at froevel.de> wrote:
> > > Hi Devs,
> > >
> > > I know you as being sensitive that all Xfce related applications are
> > > running well also at BSD-like operating systems. That's why I ask you
> > > for help.
> > >
> > > I'm the author of xfdashboard. I just implemented an application tracker
> > > which tries to determine which applications are running and marking the
> > > corresponding icon in the favourites.
> > >
> > > To archive it xfdashboard listens to newly opened windows, gets its
> > > process id and parses the enviroment variable set of the process
> > > at /proc/<<PID>>/environ. If it contains all needed environment
> > > variables and if their values are valid, then an application is
> > > considered to be running and marked. It is ok that this
> > > file /proc/<<PID>>/environ only contains the environment variables and
> > > name at the time the process was spawned. I do not need to know if they
> > > changed in the meantime.
> > >
> > > I know BSD is working a different way but I have no idea at all how BSD
> > > is working in real. So how can get this enviroment variable set under
> > > BSD? I really would like to use the algorithm at BSD as well because it
> > > is the best way I found.
> > 
> > Hey,
> > 
> > on openbsd (and netbsd) you can use the kvm_getprocs() interface which
> > will return you an array of kinfo_proc structure, which you can pass
> > to kvm_getenvv().
> > For freebsd there's probably something similar.
> 
> On FreeBSD there is libprocstat, see the man page at
> https://www.freebsd.org/cgi/man.cgi?query=libprocstat&apropos=0&sektion=0&manpath=FreeBSD+10.1-RELEASE&arch=default&format=html
> 
> It should be along the lines of procstat_open_sysctl() to get a
> pointer to a procstat struct for use with sysctl,
> procstat_getprocs() with the pid in order to get an array of
> exactly one kinfo_proc structs representing the process, and
> procstat_getenvv() to actually get the enviroment from the
> kinfo_proc.
> 
> > 
> > I don't really understand why you need to look at the environment to
> > figure out if an application is running though..
> 
> Me neither.




More information about the Xfce4-dev mailing list