Visual Studio - X11: The Display Environment Variable Is Missing

Visual Studio - X11: The DISPLAY environment variable is missing

Some nice guys of Microsoft C++ Team (thanks Ion, Erika and Elisabeth) help me and I found the solution.

The problem is related with the Visual Studio automatic generated "launch.json" file.

What "launch.json" properties I had to change:

1- Set a "name": "helloworld". The default value is " ".

2- Set "project": "CMakeLists.txt". The default value is " ".

3- Set "projectTarget": "helloworld". This property is not created automatically by VS 2019.

4- Set "cwd": "${debugInfo.defaultWorkingDirectory}". The default value is "${debugInfo.defaultRemoteDirectory}"

5- Add "export DISPLAY=:0;" inside pipeArgs

6- Remove the line "processId: 0". With this line, only the root user can deploy and debug on Linux.

7- Add a new line inside pipeArgs: "--tty=${debugInfo.tty}". This line is not automatically generated when you create a CMake Project VS2019

So pipeArgs is:

"pipeArgs": [
          "/s",
          "${debugInfo.remoteMachineId}",
          "/p",
          "${debugInfo.parentProcessId}",
          "/c",
          "export DISPLAY=:0;${debuggerCommand}",
          "--tty=${debugInfo.tty}"
        ]

No X11 DISPLAY variable - what does it mean?

If you're on the main display, then

export DISPLAY=:0.0

or if you're using csh or tcsh

setenv DISPLAY :0.0

before running your app.

Actually, I'm surprised it isn't set automatically. Are you trying to start this application from a non-graphic terminal? If not, have you modified the default .profile, .login, .bashrc or .cshrc?

Note that setting the DISPLAY to :0.0 pre-supposes that you're sitting at the main display, as I said, or at least that the main display is logged on to your user id. If it's not logged on, or it's a different userid, this will fail.

If you're coming in from another machine, and you're at the main display of that machine and it's running X, then you can use "ssh -X hostname" to connect to that host, and ssh will forward the X display back. ssh will also make sure that the DISPLAY environment variable is set correctly (providing it isn't being messed with in the various dot files I mentioned above). In a "ssh -X" session, the DISPLAY environment variable will have a value like "localhost:11.0", which will point to the socket that ssh is tunnelling to your local box.

Windows Subsystem for Linux DISPLAY variable setup

The Windows Subsystem for Linux doesn’t officially support graphical GNU/Linux desktop applications, so we have no guarantee that the calls made by our graphical program of choice will be implemented as windows system calls.

The main issue you are running into is the lack of a graphical interface to these programs, called an "X-server". We can try to get around this problem by:

1. Installing an X-server (Such as Xming).
2. Telling the Windows Subsystem for Linux to use this X-server as the DISPLAY by setting the environment variable.

For (1), to install Xming, you can just download and accept the default settings, it will automatically launch and wait for graphical programs to display.

To address (2), before you run your graphical program, run:

export DISPLAY=:0

so that bash knows where to send the graphical output of the program you're running.

Then you can try running a simple graphical program (for example gvim or python's turtle module).

Again, there is no guarantee that this will work for all GNU/Linux applications, since Microsoft has not translated every Linux system call to a Windows system call, and if the graphical program you're running makes such an unsupported call, your program may just crash.

Most of these instructions were taken from the following guide which shows how to get gvim working on Windows Subsystem for Linux:

http://www.howtogeek.com/261575/how-to-run-graphical-linux-desktop-applications-from-windows-10s-bash-shell/

---

Edit: Since you also asked about checking what's in DISPLAY, I'm adding that you can check the value of the DISPLAY variable by running:

echo $DISPLAY

(The $ ensures that bash interprets what follows as a variable, rather than a string literal. Running echo DISPLAY will just echo the string DISPLAY.)

_tkinter.TclError: no display name and no $DISPLAY environment variable

Matplotlib chooses Xwindows backend by default.
You need to set matplotlib to not use the Xwindows backend.

Add this code to the start of your script (before importing pyplot) and try again:

import matplotlib
matplotlib.use('Agg')

Or add to .config/matplotlib/matplotlibrc line backend: Agg to use non-interactive backend.

echo "backend: Agg" > ~/.config/matplotlib/matplotlibrc

Or when connect to server use ssh -X remoteMachine command to use Xwindows.

Also you may try to export display: export DISPLAY=mymachine.com:0.0.

For more info: https://matplotlib.org/faq/howto_faq.html#matplotlib-in-a-web-application-server

---

Related Topics