Moshe Kaminsky schreef:
Hi,
* Holly Bostick [EMAIL PROTECTED] [30/08/05 17:30]:
Hi all,
I was having a nice day when this started happening completely out of
the blue (no emerges, no changes, no nothing prior to what I'm about to
explain):
I use Openbox, and I finally just started setting it up to use more of
its features, notably the dock.
Now, I always ran OB from a script (pointed the exec line in the
usr/share/xsessions openbox.desktop entry to point to it), in order to
start various apps (feh, pypanel, gnome-settings-daemon, numlockx) prior
to starting OB itself.
Why do you have to modify the .desktop file? don't you have an option in
the display manager to choose the xsession file?
Yes, but when I created this script, I had ROX installed, which itself
takes over the xsession file. So I had to create a separate script in
order to use both WMs, and so I had to point the desktop file to the
OB script (as xsession was unavailable).
Even though I don't use ROX anymore, I don't know if I might at some
point try another WM that has the same behaviour, and besides, this way,
I know where the script is and what it's called (it's unique), which
(seems to) makes it easier to manage.
I usually edit the script in gedit, but I've edited out that blank line
in nano, kate, and nedit as well, and it keeps coming back (I edit it
out, save the file, try logging in via the script, error recurs).
The convention is that text files should end with an eol. I guess these
editors add it. I know vim does it, unless you explicitly ask it not to.
I can get into OB by changing the .desktop entry back to Exec=openbox
(but then of course I have nothing but the menu), and I can run the
(modified to remove 'exec openbox') script after OB has started, and all
my dockapps and helper apps appear normally.
But this is obviously not optimal (unless anyone knows a way to make OB
run the script itself when it starts, but if we could do that, we
wouldn't have to be editing ~/.xsession or writing extra scripts in the
first place).
I use fluxbox, which I think is very similar, and I can specify startup
applications in the ~/.fluxbox/apps file. But I think using ~/.xsession
is better, since then if you decide to switch to another wm, you can
just change one line in .xsession, and still have the same other apps
running.
Not all that similar. Maybe to Openbox 2, but I've never used that.
Openbox 3 is a total rewrite that is likely only called *box because
that's what it used to be called, not because it bears any real
relationship to flux/black/previous open -box.
I don't even have an ~/.xsession. And if I have to create such a file,
I'd just as soon create a unique script. That way I don't have to go
editing .xsession if I change display managers, or forego a display
manager entirely.
What I want is to permanently get rid of this bogus EOF in my script, so
that it works the way it did 3 hours ago.
As I said, I don't believe it's the problem. Can you post .xsession and
.xsession-errors?
As I said, I don't have a ~/.xsession; the only one I have is the
unmodified one in /etc.
But what's weird now is:
I opened up my script (in gedit), copied all the text, pasted it into a
new file, added the 'exec openbox' line at the end (without ending it
with a return, of course), saved it to $HOME under a new name, made the
new file executable, and logged out/in-- and it worked perfectly normally.
I'm starting to wonder if this is an X problem, or a GDM problem, or an
fglrx, or very remotely an Openbox problem; I've had random intermittent
problems with X display for the past couple of weeks, and the three
things I've done in that time have been
upgrade GDM
upgrade the fglrx drivers (which I'm about to downgrade again)
play with the fglrx options (to see if they helped the driver work).
I also seem to be having a serious heat problem (the CPU is running very
very hot), and though the system seems stable (i.e., it doesn't lock or
crash), I suppose that could also cause random intermittent and
seemingly untrackable problems as well.
But thanks for the help; I guess I've got enough possible vectors to
examine on my own that I shouldn't have bothered the list, but it was
just so weird to see a script that I've been using for over a year
should suddenly fail out of the blue.
Holly
--
gentoo-user@gentoo.org mailing list
