KDE 4.3.4 cannot start

[Duncan]

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 excerpted:
>> 
>>> However, these instructions are wrong:
>>> 
>>> http://cblfs.cross-lfs.org/index.php/Starting_KDE
>>> 
>>> I suggest that you try this for your ~/.xinitrc file:
>>> 
>>> ------8<------8<------8<------8<------8<------8<------8<------8<------
>>> 
>>> 
>>> eval `dbus-launch --sh-syntax --exit-with-session`
>>> 
>>> exec startkde
>>> 
>>> ------8<------8<------8<------8<------8<------8<------8<------8<------
>>> 
>>> 
>> 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.  Presumably, the 
user may have several other things already setup to run when starting X, 
and would not want them to be overwritten.  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.  (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.)

> 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 exported).

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 line.

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 well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.