in reply to Re^2: How to detect X?
in thread How to detect X?

I've clarified the part where you seem to misunderstand my statement.

Restated, it is that I make no assumptions about where the X server is.

As for non-X environments: if you're in a non-X environment, and do not want to use an X server, then you should not be running X-based programs. HP's "sam" comes to mind again - if I want to run "sam" without the GUI, I have to unset DISPLAY. Maybe HP isn't the epitome of user-friendly unix-based software. Maybe it is. I don't know. But there is precedent for the OP's request, and it is to follow this convention that you don't seem to follow. Just because one person doesn't follow a convention doesn't mean the convention doesn't exist. Sorta like the leading underscores on "private" functions in perl modules...

Update: Noticing that you point out that "A implies B" does not mean "B implies A". However, what you seem to misunderstand is that "A represents B". The DISPLAY variable represents the X-based display. And thus, if you set it and it's set incorrectly, then you have an incorrectly set display, and the program cannot figure out whether this was intentional or not, and would properly, IMO, refuse to run. No point in bringing up an ugly TUI if the user's environment says "I want a GUI".

Replies are listed 'Best First'.
Re^4: How to detect X?
by Anonymous Monk on Feb 22, 2005 at 10:42 UTC
    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.
[reply]

      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]

In Section Seekers of Perl Wisdom