Once upon a time Lukas Latz said... > Barry, > > su -m surely does it. So what property that's carried over is it that > makes the difference?
The difference is $HOME. If you use just 'su', your user environment is inherited by the root shell, except for some variables that get replaced by su. One of those is $HOME - it gets set to root's home directory. With su -m, $HOME stays as it was and is still set to your home directory, even though you are root. In both cases $DISPLAY is retained - so that is not the difference. The reason $HOME makes a difference is that it is used to find the .Xauthority file. When you start an X program, it looks in $HOME/.Xauthority for the magic cookie that lets the program connect to the X server. Normally only the user can read this file, but root can see all, so it can use it too. If $HOME changes (as it does with a plain "su"), there is no longer an .Xauthority file. An alternative to "su -m" is to use "su" but set the environment variable XAUTHORITY to point to the user's .Xauthority file. eg. $ su Password: # XAUTHORITY=/home/lukas/.Xauthority ; export XAUTHORITY # xterm In this case, xterm should work. This trick will not work if you home directory is mounted via NFS, since root on your machine does not have root level privileges on an NFS mounted filesystem (by default - that can be overridden). BTW. If you were to do "su -", you'd start with a clean environment so you'd have to set both DISPLAY and XAUTHORITY. Apparently the proper way to handle this .Xauthority stuff is to use the xauth(1) program to export and import cookies, but I found that to be too much trouble to figure out properly for all cases. Mostly I use ssh now, with X11 forwarding which also solves the problem. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
