Re^4: How to detect X?

and the program cannot figure out whether this was intentional or not, and would properly, IMO, refuse to run

But that's what this entire problem is about. How to detect whether X is running or not. The existance of a DISPLAY variable does not mean X is up and running. Just like the existence of PERL5OPT does not mean we're currently being executed by a Perl program. DISPLAY makes sense for X applications. PERL5OPT makes sense for Perl applications. But that's about it. X applications will not run correctly if DISPLAY isn't set up - you are right about that. But that doesn't mean that non X-applications (and the OP's application might present itself as a non-X application) will, or should, refuse to run if a DISPLAY variable is set. The DISPLAY variable does not imply the user saying "I want a GUI". All it says "if I'm going to launch an X-application, that's where I want it to display itself". It's not that firefox downgrades itself to a text-mode browser if it finds out DISPLAY isn't set.

Comment on Re^4: How to detect X?

Replies are listed 'Best First'.
Re^5: How to detect X? by Tanktalus (Canon) on Feb 22, 2005 at 15:09 UTC
I think you're missing the point of DISPLAY. It's there to point at an X server. If you have it set, you're telling programs that X is there. If you have PERL5OPT, about all you're telling programs is that you use perl, not that you're using perl for the current application. I think a better example would be ORACLE_HOME or DB2INSTANCE - if you've got these set, you're telling applications where to find Oracle, or that you're in a DB2 environment. Neither one may be working, but if I'm an application which relies on either Oracle or DB2 (perhaps with a fall-back), I'm going to read these to find out where to find Oracle or DB2. And, if they're set up incorrectly, I don't think it's unreasonable for me to fail with some error message complaining about these variables. Same thing as DISPLAY. DISPLAY is there to set up X. If you're not using X, then you're misleading the applications that use X. Convention says that if DISPLAY is set, you may attempt to use it. If authentication fails, you then exit with an error message. This may mean that you set DISPLAY incorrectly (and wish a chance to set it properly), or that you shouldn't have DISPLAY set at all (and then you can unset it, and retry, assuming the application in question supports a non-GUI interface).	[reply]

Replies are listed 'Best First'.

Re^5: How to detect X?
by Tanktalus (Canon) on Feb 22, 2005 at 15:09 UTC

I think you're missing the point of DISPLAY. It's there to point at an X server. If you have it set, you're telling programs that X is there. If you have PERL5OPT, about all you're telling programs is that you use perl, not that you're using perl for the current application. I think a better example would be ORACLE_HOME or DB2INSTANCE - if you've got these set, you're telling applications where to find Oracle, or that you're in a DB2 environment. Neither one may be working, but if I'm an application which relies on either Oracle or DB2 (perhaps with a fall-back), I'm going to read these to find out where to find Oracle or DB2. And, if they're set up incorrectly, I don't think it's unreasonable for me to fail with some error message complaining about these variables.

Same thing as DISPLAY. DISPLAY is there to set up X. If you're not using X, then you're misleading the applications that use X. Convention says that if DISPLAY is set, you may attempt to use it. If authentication fails, you then exit with an error message. This may mean that you set DISPLAY incorrectly (and wish a chance to set it properly), or that you shouldn't have DISPLAY set at all (and then you can unset it, and retry, assuming the application in question supports a non-GUI interface).

[reply]