Effect: XFce does not start when dbus (e.g. version 0.23.4; doesn't matter here) is installed. Error message: DBUS_SESSION_BUS_PID=12345: is not an identifier Cause: In the startxfce4 script on line 35, $prog is assigned the value /bin/sh. $prog is then used to exec XFce's xinitrc. In that file on line 67, the result of dbus-launch is handed over to eval. Explanation: On Sparc/Solaris, the eval fails because /bin/sh is not bash and not capable of handling something like "export foo bar=val" which it would have to in order to process the output correctly: A typical dbus --sh-syntax --exit-with-session gives something like this: DBUS_SESSION_BUS_ADDRESS='unix:path=/tmp/dbus-somesalt' export DBUS_SESSION_BUS_ADDRESS DBUS_SESSION_BUS_PID=12345 but when executed by /bin/sh through eval: DBUS_SESSION_BUS_PID=12345: is not an identifier because eval automatically replaces newlines in the output of dbus-launch by spaces and /bin/sh cannot cope with that, unlike bash. If dbus-launch wrote a semicolon after each output line, there would be no problem either. Possible solution: Replacing prog=/bin/sh by prog=/bin/bash in startxfce4 on systems that have bash installed does the trick. However, I don't know if one can assume that there is a bash on a standard Solaris system. :-/ The problem probably still exists in XFce 4.2.2.
I don't have a non bash shell to test with, but does replacing the offending eval with a simple /bin/sh resolve the problem? I ain't a shell scripter of any merit, but shouldn't that bypass eval's mangling of the dbus-launch output?
(In reply to comment #1) > I don't have a non bash shell to test with, but does replacing the offending > eval with a simple /bin/sh resolve the problem? I ain't a shell scripter of any > merit, but shouldn't that bypass eval's mangling of the dbus-launch output? I don't think this will work. The eval function is used because the output of dbus-launch is environment declarations that need to be added to the environment of the /current/ shell. If you use /bin/sh for calling dbus-launch, the environment of that subshell will be modified and not the one of the current shell. However, other processes spawned from the current shell will only inherit the environment of the current shell, not of any subshell. I think the right way to go is to use bash for execution of the scripts. However, I don't know about other platforms and why /bin/sh is used at all. Sure, bash is not installed everywhere right from the start. But if there is no other way than using the eval function here, I vote for using /bin/bash for $prog or at least make sure that it is bash compatible.
I think the proper solution here is to fix D-BUS. Please report this bug to the D-BUS developers.