You can do that like so: sudo visudo -f /etc/sudoers.d/localīut wait, what if none of the above works?
#Gzdoom command line upgrade
I recommend putting the line not in the default sudoers file ( /etc/sudoers), but in a local file that won't get overwritten when you upgrade your system. You can check what environment variables sudo preserves by running: sudo sudo -V The "correct" way to do it is to add the line Defaults env_keep += "DISPLAY XAUTHORITY" to the sudoers(5) file using visudo(8). Environment variables affect the way programs work and you don't want them all being exported from a user account to the root. You might well ask, Wait, if -E makes everything magically work, then why isn't it the default for sudo? The answer is that it is a potential security hazard. So, what's the fix? If either the DISPLAY or the XAUTHORITY environment variables aren't getting saved across the sudo, you can tell sudo(8) to preserve the environment by using the -E option, like so: sudo -E evince If XAUTHORITY is pointing to a file in your home directory for you, but it's blank when you run sudo, then that's the problem. Again, let's check if it is properly set in sudo: echo $XAUTHORITY The most commonly used one today is xauth(1) which uses the XAUTHORITY environment variable. XAUTHORITYīut, what if that's not the problem and the DISPLAY is set correctly in sudo? Then you might wonder, does X have some sort of permissions that prevent other users from writing on my display? If you thought that, you'd be right, X has two main authorization methods: xauth and xhost.
If it doesn't show anything, then that's the problem. You can see what your X display is by checking the DISPLAY environment variable: echo $DISPLAYĪnd you can check what sudo thinks your DISPLAY is by typing: sudo -s Any program that wants to write to your screen has to know the address. Your next question might be, what is this "X display" that evince can't open? A "display" is the address for your screen. Knowing that should raise many troubleshooting questions in your mind. In particular, searching for No protocol specified or WARNING **: Could not open X display, should show you that the problem is with X (also called The X Windowing System) which is how graphical programs are shown on your screen. To start, look at the first error messages first.
#Gzdoom command line how to
That means you're interested in not only what the fix is, but also how to figure it out on your own. Your second question, "How to troubleshoot this problem?" is a very good one. Note that XDG_RUNTIME_DIR is set by pam_systemd(8), so it is not actually related to X (running programs graphically), which is the problem you seem to be having. It tells any program you run where to find a user-specific directory in which it can store small temporary files. To answer your first question, "What is XDG_RUNTIME_DIR?", it is an environment variable that is set automatically when you log in.
0 kommentar(er)
