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

Lots of applications will fail,
Really? For years, I would set $ENV{DISPLAY} in my profile (so if I would telnet/rsh/rlogin to another box, things would display at my screen - and if I started X somewhere else, DISPLAY would be reset). Yet, I would never had an application fail because of that.

See, if you don't have X running, X applications will fail. Not because $ENV{DISPLAY} is set, but because X isn't running. Non X-application don't give a shit about $ENV{DISPLAY}. The only thing that could "fail" is an X-application displaying on the wrong screen - but that would only happen if the environment had not setup $ENV{DISPLAY} - and then it would use a default variable instead of being undefined. Ho hum.

Using DISPLAY is just the convention with X.
Indeed. The fallacy in your reasoning is that there's also a convention about DISPLAY (namely, it being unset) in a non-X environment. Unfortunally, that isn't true.

Replies are listed 'Best First'.
Re^3: How to detect X?
by Tanktalus (Canon) on Feb 21, 2005 at 17:14 UTC

    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".

[reply]
      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]
Re^3: How to detect X?
by jdporter (Paladin) on Feb 21, 2005 at 19:10 UTC
    The fallacy in your reasoning is that there's also a convention about DISPLAY (namely, it being unset) in a non-X environment.
    Depends on what you mean by "non-X environment". Theoretically, any platform could define its own standards/conventions for the use of the DISPLAY variable; X doesn't "own" it. But I don't know of any. Do you? If you're talking about some home-brewed application that uses DISPLAY for its own purposes — well, the author (and users) of such a thing are SOL for potentially conflicting with X. And this is one of the reasons why Global Variables Are Evil. :-)
[reply]
      My point isn't that other applications would set or use DISPLAY. It just means that DISPLAY could be set (from someone's profile) even if X isn't running.

      Just like that PERL5LIB is set if I run a Python program. Nothing but Perl is using PERL5LIB as far as I know, but that doesn't imply that if PERL5LIB is set, I'm running perl.

[reply]
        How DISPLAY is used and how PERL5LIB is used are not at all analogous.
[reply]

In Section Seekers of Perl Wisdom