KDE 4.3.4 cannot start
jrtyrer at earthlink.net
Sat Jan 9 10:23:53 GMT 2010
> James Tyrer posted on Thu, 07 Jan 2010 11:11:15 -0700 as excerpted:
>> Duncan wrote:
>>> James Tyrer posted on Wed, 06 Jan 2010 16:07:26 -0700 as
>>>> However, these instructions are wrong:
>>>> I suggest that you try this for your ~/.xinitrc file:
>>>> eval `dbus-launch --sh-syntax --exit-with-session`
>>>> exec startkde
>>> According to the dbus-launch manpage I have here, the
>>> instructions at the given URL (the starting dbus ones) appear to
>>> do about the same thing, except that dbus instance should start
>>> and stop with the session, which is what's desired if you're
>>> doing it that way. Why are they wrong?
>>> Here's the (single) line they use (minus the echo to the
>>> ~/.xinitrc bit), reprinted here for comparison:
>>> exec dbus-launch --exit-with-session startkde
>> First, there is an error is in this line:
>> echo "exec dbus-launch --exit-with-session startkde" >> ~/.xinitrc
>> Note the ">>", that is wrong.
> Why is that wrong? It's the file-redirect and append (instead of
> replacing). Thus, it appends that line to the end of .xinitrc if it
> exists already, and creates it with that line, if not.
You should use one or the other of the commands to replace "~/.xinitrc",
not both: "use the following command instead of the one shown above".
If you append:
exec dbus-launch --exit-with-session startkde
to "~/.xinitrc" and there is an "exec" command before it, control will
never reach that line.
> Presumably, the user may have several other things already setup to
> run when starting X, and would not want them to be overwritten.
Absolutely correct and that is why you should edit the file rather than
just using the "echo" command. However, if there is an "exec" command,
that would need to be removed.
> Also, because it's an exec, the new command runs in the existing
> process, replacing the bash code running the script with the
> dbus-launch program, so you wouldn't want it anywhere else /but/ the
> end of an existing .xinitrc, since it's not conditional, and if it
> were any place but the bottom, the rest of the script wouldn't get
> run. So, appending to the existing file (if it exists) would seem to
> be exactly the intended effect.
But, not if there is already an "exec" command.
What I think is likely is that people will not read the page and will
echo "exec startkde" > ~/.xinitrc
echo "exec dbus-launch --exit-with-session startkde" >> ~/.xinitrc
and it obviously will not start D-Bus.
IAC, they should both just have either ">" or ">>", there is no reason
for one to have one and one the other.
> (They do mention to be sure there's no other WMs started above it,
> however, which would again be desired, and confirms the intent to
> have what's there remain and continue to function, just now, with the
> new line invoking dbus to startkde.)
And that is why you should edit the file rather than use the "echo" lines.
>> I have to say that I do not know exactly why the D-Bus
>> documentation said to do this:
>> eval `dbus-launch --sh-syntax --exit-with-session`
>> as you probably know, using "eval" make the command take effect in
>> the current Bash session. Which appears to be what you want.
> Well, there's basically two ways to accomplish the same thing --
> arranging for the dbus-launcher to track the session that's doing the
> startx. Using the eval method, it runs it in the same session, but
> the launcher then forks off the daemon (after getting the info about
> the session that it needs so it can track it) and returns control to
> the script, while printing the necessary dbus info for the WM (using
> --sh- syntax) to STDOUT. The eval then takes are of setting up the
> environment from that output, such that an exec of the WM launcher
> (startkde in our case) further down the script will have the
> information about the dbus instance that the wm launcher needs all
> setup. The two sides thus know about each other, and the dbus daemon
> can track the wm session and shut down when it does. This method
> does the dbus launch first, then later, the wm launch-exec, on a
> different line.
> The other way to do it is as that kde page mentions, all in one line.
> When a program is supplied to dbus-launcher as a parameter (it's the
> only non-option argument, with everything following being args for
> the invoked program), dbus-launcher itself launches it (as well as
> dbus), setting the environment appropriately before doing so. As
> such, the dbus-launcher invoking script no longer needs to know the
> information otherwise handed to it on STDOUT, so in that case, STDOUT
> doesn't get it. Since dbus- launcher takes care of setting up the
> WM-launcher in this case, the two are accomplished all on the same
> line, with no second line needed (which is of course the reason for
> the exec in that case, it's slightly more efficient reusing the same
> process instead of setting up a new one, and that makes sure any
> other environment settings, etc, carry over, even if they're not
> So, unless I've seriously missed something, I don't see what's wrong
> with either method. They're just two different ways of doing the
> same thing, one running dbus-launch first, as a separate command,
> then the WM- launcher, the second handing the WM-launcher to
> dbus-launch as a parameter, so it's all accomplished in a single
> That's why I'm asking what's wrong. Because I can't figure it out,
> but I've been known to overlook the obvious on occasion, and in fact
> am still learning "neat bash tricks" (and unfortunate bash
> misunderstandings) myself, so I'm just wondering if this is a "neat
> dbus-launcher trick" (and/or a bash redirect trick) you didn't
> understand, or an "unfortunate bash misunderstanding" of my own.
> Either way, I'm learning stuff, and expect you might be doing so as
I think that the question is whether:
eval `dbus-launch --sh-syntax --exit-with-session`
dbus-launch --sh-syntax --exit-with-session
will have the same effect. IIUC, they will not.
Linux (mostly) From Scratch
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
More information about the kde