As I said in my other thread, I just came over to Slackware from Gentoo. When I was on Gentoo, I had cron run two backup scripts, one on the first of every month, and the other every single day. The first of the month script would back up the entire /etc and /home directories, while the everyday script would only back up files in those to directories that had changed since the previous day. All files are then dropped in /backup/<hostname>/YYYYMM/ and they are burned to a DVD four times a year. As one can imagine, it is vitally important when using a scheme such as this to keep archive sizes down so that the total doesn't go over 4.3GB. On Slack the /etc backup becomes less important, but the /home backup remains important. I keep a terminal open at all times with multiple tabs. One of those tabs is always running a su session. But when I try to run any X app, I get this:
root@caitlyn:~/gnumeric# file-roller
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications.
No protocol specified

** (file-roller:14811): CRITICAL **: Failed to parse arguments: Cannot open display:
root@caitlyn:~/gnumeric#

I have researched this some, and found no threads with similar enough circumstances to be helpful. I had this problem on RH almost twenty years ago, but have forgotten what the fix was. I have tried adding xhost +localhost to /home/michael/.bashrc in an attempt to workaround this issue, but it didn't work. Please help!

I just add to my ~/.bashrc this line:There are certainly better ways, but it works.

That worked. Thank you!!! Now how do I mark this thread [SOLVED]?

Click on Thread Tools at the top right of your first post. Solved is in the drop down box.

Thank you again.

There are other options, if you don't want to manually specify that in your .bashrc. Namely, you can set the DISPLAY variable manually:

Also, I would suggest switching to kdesu instead of regular su to launch GUI programs as root within another user's session. Some programs will use the regular user's directory for their data, which can change the permissions or ownership of that data, causing the programs to have issues when run again as a regular user. This is easily solved after-the-fact using chown, but using kdesu will completely prevent it from occurring in the first place.

2 members found this post helpful.

Thanks for the hint bassmadrigal !

I've never heard of kdesu until you mentioned it just now.

I suppose I need to RTFM more often.

Speaking of the fine manual, man kdesu has a nice synopsis of kdesu.

Thanks again !

-- kjh

@bassmadrigal: Thanks also for the hint and the suggestion to use kdesu. By the way, people who do not have the KDE series installed or prefer not run KDE apps if there are other options can also use ktsuss or gksu, both available @ slackbuilds.org.

Didier,

I just tried gksu and was quite dissatisfied. I compiled it to work in an
xterm per the instructions at Slackbuilds. When I tried to use it, it asked me
for my root password as expected, then ask for the password for "pulse", whatever
that is. When I tried again, it didn't as for the pulse password, but none of the
arrow keys would work. The keycodes for them were printed on the screen, but no
movement occured. I'm looking further into this. Maybe I left something out
but don't know what it could be at the moment.

Worsel

Worsel,

unfortunately I can't help here as I use ktsuss that is shipped in Slint. It doesn't have as many features as kdesu, buts suffices for my needs.

I use ktsuss here too, not very often, but when I need something like that its easily the quickest and simplest solution.