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
