so the kernel can send d-bus messages

Maciej Katafiasz mnews22 at
Mon Jul 26 02:42:00 PDT 2004

Dnia 25-07-2004, nie o godzinie 23:27 -0400, Havoc Pennington napisał:
> > But I must ask - why is the default socket for session bus name
> > constructed by appending random junk to /tmp/dbus, instead of
> > predictable scheme like /tmp/$username/dbus-session? If it's for
> > security reasons, aren't permissions enough to make sure noone's trying
> > to spoof? That would eliminate need for the env variable set in 95% of
> > cases (ie. all default setups).
> Right, the "well known filename" approach is a different way to locate
> the bus. It has a couple of problems.
> 1. the bus is supposed to be per-session, not per-user

Hmm, right.

> 2. anyone can create /tmp/$username/dbus-session, not only $username

That can be solved by O_EXCL and falling back to random name + env var
if necessary :)

> Again, if you have a working alternate to the env variable, I'd love to
> hear it. ;-) But afaik there's no other way to do it.

I do not. That's the point of this thread ;)

> At some point you have to define some unique ID, or process, or
> something, that defines the session. And whatever that is, the env
> variable is the only way I can think of to let apps know what it is.

Currently, it looks like it's indeed the only way. Let's change that :)

> > That isn't exactly my point. Let's leave aside session bus and grounding
> > points for a while, what I'm seeking for is a way to store and _change_
> > settings currently managed with env vars, similarly to what XSETTINGS
> > mechanism provides for X. That would be one part (apparently, the easy
> > one) of solution for "how to change locale session-wide without logging
> > out" problem (the second one is of course refactoring apps around
> > changing values of LC_*, that's particularly big undertaking, but I
> > digress). 
> Yes, the hard part about changing locale is printf.
> Apps are packed with stuff like:
>  char *s = g_strdup_printf (gettext ("blah blah %s blah blah %d blah
> blah %f"), mystring, myint, myfloat);
>  gtk_label_set_text (label, s);
> Now, to change the the text in the label dynamically, you will need to
> keep around mystring, myint, and myfloat, and redo the printf when the
> locale changes.
> You also need to call gettext() again, that would be relatively easy:
>  gtk_label_set_text_untranslated(label, "blah blah")
> which could be defined to call gettext() on the untranslated text, and
> keep the untranslated text around and call gettext() again on locale
> change. But you need to also keep around the printf format args and that
> seems kind of impossible to do with an API that's usable.
> I suppose we're getting a bit off-topic. 

Slightly ;)

> > One could argue GConf already provides that, but GConf is too complete,
> > too high in stack, and has too many dependencies to really be feasible
> > solution, and also doesn't do exactly what's needed (ie. you can't have
> > possibly separate settings for some apps). Ideally, that would be
> > kernel/libc-level mechanism, just like env vars are today, but that has
> > some issues with portability to non-Linux (and maybe *BSD) Unices. What
> > is needed is some way to get easy, light, changeable at runtime env vars
> > on steroids.
> > 
> > I hope I was clearer this time, and that someone indeed knows how to
> > achieve that :)
> I think if you apply my suggested changes to gconf you would have what
> you need, more or less:

Well, whatever the replacement is, it must be able to provide all of
current functionality of env vars, namely ability to set it
independently for each app (but with added possibility to change that
later, and not only strictly down the process tree). Ideally, it would
have all the pros of env vars - dead simplicity, comes for free with
libc, and is available everywhere.

> But I don't know exactly what you're looking for. Again, a bit offtopic,
> xdg at freedesktop might be better.

I suppose it is off-topic. XDG is probably the best place, will move the
thread there.


"Tautologizm to coś tautologicznego"
   Maciej Katafiasz <mnews2 at>

More information about the dbus mailing list