! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
startxfce4 fails on Sparc/Solaris when dbus is installed
Status:
RESOLVED: WONTFIX
Product:
Xfce-utils
Component:
General

Comments

Description Jens Hatlak 2005-07-05 17:11:16 CEST
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.
Comment 1 Erik Harrison 2005-07-17 03:58:17 CEST
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?
Comment 2 Jens Hatlak 2005-07-17 07:15:49 CEST
(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.
Comment 3 Brian J. Tarricone (not reading bugmail) 2005-10-15 11:51:09 CEST
I think the proper solution here is to fix D-BUS.  Please report this bug to the
D-BUS developers.

Bug #1060

Reported by:
Jens Hatlak
Reported on: 2005-07-05
Last modified on: 2009-07-14

People

Assignee:
Xfce Bug Triage
CC List:
0 users

Version

Attachments

Additional information