I can run Linux GUI applications via terminal, but can't run via wsl-windows-toolbar.

[haosmos]

My environment:

Windows 10 OS version: 2004 OS build: 20190.1000 (insider preview "dev") WSL: Ubuntu-20.04.1 Linux kernel: 4.19.121 X-server: VcXsrv Ubuntu desktop environment: KDE plasma

Can you tell me, please, why Linux applications don't run via wsl-toolbar, but they run through a terminal?

For reasons I don't understand, I can't run Linux GUI applications with the DISPLAY variable defined in the recommended way:

export DISPLAY=$(grep -m 1 nameserver /etc/resolv.conf | awk '{print $2}'):0.0.

Instead of this command, I use the IPv4 address: 192.168.0.107 as the value of the DISPLAY variable.

I found this value of the DISPLAY variable by a random choice method and the applications started to run.

In my .zshrc file I put the following lines of code — as recommended in the already closed question: https://github.com/cascadium/wsl-windows-toolbar-launcher/issues/4:

export DISPLAY=192.168.0.107:0.0
# If not running interactively, don't do anything (wsl-launcher)
[ -z "$PS1" ] && return

Still, applications are not launched via wsl-toolbar.

I can run Linux GUI applications through the terminal, but can't via wsl-windows-toolbar.

Tell me, please, what other information do I need to give you so that you can determine what I did wrong?

[fquinner]

Hi there! The script uses bash by default so you can either put the variable in your bash profile or else use an alternative -J template which uses zsh instead (the one that the script uses is https://github.com/cascadium/wsl-windows-toolbar-launcher/blob/master/wsl-windows-toolbar-template.sh.j2 so you can copy and hack that for zsh shebang).

If the DISPLAY variable doesn't work with the recommended command there is probably a firewall rule preventing it. These installers on windows tend to sneak in a block rule for "public" networks which (idiotically) the wsl network falls under. This block rule will take precedence over any allow rule you may have created. There's some info on the README for the sort of things to check for there.

I tend to prefer not to use public or private "real" IPs at all since that opens up your x11 port to anyone else who happens to be on your network, but that's a matter of personal preference.

[haosmos]

Hi, @fquinner! Thank you for your recommendations!

The script uses bash by default so you can either put the variable in your bash profile

— sorry, I didn't quite understand you — you recommend placing this code:

export DISPLAY=192.168.0.107:0.0
# If not running interactively, don't do anything (wsl-launcher)
[ -z "$PS1" ] && return

in my ".bash_profile" file? Or in my ".bashrc" file?

or else use an alternative -J template which uses zsh instead (the one that the script uses is https://github.com/cascadium/wsl-windows-toolbar-launcher/blob/master/wsl-windows-toolbar-template.sh.j2 so you can copy and hack that for zsh shebang).

— I would gladly try to do what you recommend, only I do not understand what you are talking about at all))😜 This is because I am not good at linux)).

If it's not difficult for you, please explain in more detail)

I tend to prefer not to use public or private "real" IPs at all since that opens up your x11 port to anyone else who happens to be on your network, but that's a matter of personal preference.

— I wouldn't want to use public or private "real" Is too, but I don't know how to do it))

But that's another question))

[fquinner]

Hehe sorry when I saw zsh I assumed you were a pro with Linux since most default shells are bash. It depends on your distros setup but usually its .bashrc. When you open a new terminal in wsl and you run echo $SHELL, what does it say?

[haosmos]

Hehe sorry when I saw zsh I assumed you were a pro with Linux since most default shells are bash. It depends on your distros setup but usually its .bashrc. When you open a new terminal in wsl and you run echo $SHELL, what does it say?

echo $SHELL
/bin/zsh

[haosmos]

It depends on your distros setup but usually its .bashrc.

— I tried to put the code:

export DISPLAY=192.168.0.107:0.0
# If not running interactively, don't do anything (wsl-launcher)
[ -z "$PS1" ] && return

in .bashrc file.

But it didn't help either 😪

[fquinner]

You could try adding:

source ~/.bashrc

To your .bash_profile as well.

I'm afk at the moment but when I get to a machine I can try and get the wsl command to help you troubleshoot exactly what's happening here - I wouldn't be sure off the top of my head.

[fquinner]

If you run:

wsl.exe -d <your-distro-name> --exec bash -l

from a windows command prompt, then:

echo $DISPLAY

That should let you know whether or not $DISPLAY gets set correctly for your bash environment (and if your .bashrc etc files get parsed) to help you figure out what's going on here.

[haosmos]

@fquinner, thank you!

If you run:

wsl.exe -d <your-distro-name> --exec bash -l

from a windows command prompt, then:

echo $DISPLAY

That should let you know whether or not $DISPLAY gets set correctly for your bash environment (and if your .bashrc etc files get parsed) to help you figure out what's going on here.

When I executed the command:

wsl.exe -d <your-distro-name> --exec bash -l

From the windows command line, there was a welcome message from wsl, in other words, this command switched me to wsl.

And I had already executed the command from wsl:

echo $DISPLAY

gives the following result:

192.168.0.107:0.0

This happens if I specify it in my .zshrc file as a form:

export DISPLAY=192.168.0.107:0.0

If I comment this command and specify the value of the variable $DISPLAY in the form:

export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0

The result will be this: the same welcome message from wsl will be output and I will also be switched to wsl from CMD (windows).

And the command echo $DISPLAY

gives the following result:

172.30.160.1:0.0

This value coincides with the value of the wsl address (Ethernet vEthernet (WSL)) which shows PowerShell by the ipconfig command.

Interestingly, after that I can run a Linux GUI application through a terminal, but still not through a wsl-toolbar.

If I move this code:

export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0
# If not running interactively, don't do anything (wsl-launcher)
[ -z "$PS1" ] && return

from .zshrc to .bashrc (I disable this code in .zshrc with the comment "#"), I can still run Linux GUI applications.

But when I execute the command that you suggested:

wsl.exe -d Ubuntu-20.04 --exec bash -l

I am again switched from cmd (windows) to wsl, but after that the value of $DISPLAY probably changes or I lose the ability to contact it or something else happens and I can no longer run Linux applications.

But when I activate the code again

export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0
# If not running interactively, don't do anything (wsl-launcher)
[ -z "$PS1" ] && return

in .zshrc and execute the command

wsl.exe -d Ubuntu-20.04 --exec bash -l

then I am switched from cmd (windows) to wsl again and the value of $DISPLAY again matches the value of Ethernet vEthernet (WSL) and I can run GUI Linux applications again.

I recorded a video showing all these steps: https://yadi.sk/i/haXrQJ1wMp4sKQ.

I don't know, maybe the reason is that I am trying to configure systemd in parallel. The first time I run wsl - systemd is activated (and I can run snapd and snap packages), but for some reason, it disables commands like "code" or "explorer.exe .

I've published a question in the corresponding topic and it's probably not related to my current wsl-toolbar problem. But who knows, maybe it has something to do with it. Because after running the command.

wsl.exe -d Ubuntu-20.04 --exec bash -l

systemd is activated and commands such as "code" or "explorer.exe ." are disabled. Here is a link to a short video (2m 30sec) of my problem with systemd https://yadi.sk/i/gRPIMDwaDqt6uw.

Oh my God, what a huge post and so many questions from me, sorry, please).

[fquinner]

Hi @haosmos, Looking at the video, i see this in your .bashrc:

Which will get bash to run zsh again etc - you should take everything from line 10-15 inclusive in .bashrc out because that won't help your case.

I think the best .bashrc you could have at the moment is one which has some debug statements inside like:

echo "Yes I am getting parsed :)"
export DISPLAY= .... your stuff ...
echo "DISPLAY=$DISPLAY

That way you can be confident that the right file is getting sourced.

That wsl.exe -d Ubuntu-20.04 --exec bash -l command is key because that is pretty much what the toolbar does - that's a standard login shell for a fresh bash session. If DISPLAY is not set in that environment (as it didn't seem to be in your video), it won't work, so best bet is to troubleshoot that as above first.

[haosmos]

I'm not sure I understood you correctly, but this is what I did:

I put this code:

echo "Yes I am getting parsed :)"
export DISPLAY=$(cat /etc/resolv.conf | grep nameserver | awk '{print $2; exit;}'):0.0
echo "DISPLAY=$DISPLAY

in the .bashrc file and commented ("#") on these lines in the .bashrc file:

bash -c zsh

Switch to ZSH shell
if test -t 1; then
exec zsh
fi

As I understood it, to disable switching to the zch shell.

After that I executed the command from CMD:

wsl.exe -d Ubuntu-20.04 --exec bash -l

The value of $DISPLAY was printed the same as that shown by powershell - 172.23.48.1:0.0.

Linux applications run from a terminal but not from wsl-toolbar.

And for some reason shell switched back to zch:

echo $SHELL                                                                                                   
/bin/zsh

😞😕

[fquinner]

Hmm there must be something on down which is switching you back to .bashrc. My point was more when you run this command, does "Yes I am getting parsed :)" get printed to make sure you're getting that far.

Maybe we should just embrace it and lean into zsh (which is what i meant originally but I'm at a computer now :))

1. Passing --rc-file ~/.zshrc to your toolbar launcher script command (though that launches within bash so could cause issues, but is the least invasive option)
2. Using --jinja-template-shell /path/to/template.j2 where template.j2 is a file with these contents:

#!/bin/zsh -i

~/.zshrc

{% if exec_dir is defined and exec_dir != "" %}

cd "{{exec_dir}}"

{% endif %}

{% if run_in_terminal is defined and run_in_terminal == True %}

{{command}}

{% else %}

{{command}} > /dev/null 2>&1 &
disown

{% endif %}

[haosmos]

Hmm there must be something on down which is switching you back to .bashrc. My point was more when you run this command, does "Yes I am getting parsed :)" get printed to make sure you're getting that far.

Maybe we should just embrace it and lean into zsh (which is what i meant originally but I'm at a computer now :))

1. Passing --rc-file ~/.zshrc to your toolbar launcher script command (though that launches within bash so could cause issues, but is the least invasive option)
2. Using --jinja-template-shell /path/to/template.j2 where template.j2 is a file with these contents:

#!/bin/zsh -i

~/.zshrc

{% if exec_dir is defined and exec_dir != "" %}

cd "{{exec_dir}}"

{% endif %}

{% if run_in_terminal is defined and run_in_terminal == True %}

{{command}}

{% else %}

{{command}} > /dev/null 2>&1 &
disown

{% endif %}

Thank you, @fquinner!

Excuse me, but I'm not sure what exactly I need to do: do I need to put this code in my .zshrc file, or do I need to execute this code in a terminal?

[fquinner]

It's a case of either doing point 1. or point 2.

Point 1 on its own may work (simply passing --rc-file ~/.zshrc to the wsl toolbar launcher script)

If not, you can try point 2 which involves creating a file accessible from wsl with the contents listed above and passing the path to that file into the script as a command line argument to the wsl toolbar launcher script --jinja-template-shell /path/to/template.j2

[haosmos]

Point 1 on its own may work (simply passing --rc-file ~/.zshrc to the wsl toolbar launcher script)

— When I execute this code in a terminal (wsl), I get an error:

> --rc-file ~/.zshrc                                                                                           
zsh: command not found: --rc-file

Or did I misunderstand you and need to do something else in Point 1?

[fquinner]

Its an argument to the script which generates the menu. E.g. wsl-windows-toolbar --rc-file ~/.zshrc

[haosmos]

Its an argument to the script which generates the menu. E.g. wsl-windows-toolbar --rc-file ~/.zshrc

— After executing the command, the following result was displayed in the console:

> wsl-windows-toolbar --rc-file ~/.zshrc                                                                        
2020-08-26 22:10:08,492[INFO]: distribution = Ubuntu-20.04
2020-08-26 22:10:08,492[INFO]: user = haosmos
2020-08-26 22:10:08,493[INFO]: confirm_yes = False
2020-08-26 22:10:08,493[INFO]: menu_file = /etc/xdg/menus/gnome-applications.menu
2020-08-26 22:10:08,493[INFO]: wsl_executable = C:\Windows\System32\wsl.exe
2020-08-26 22:10:08,493[INFO]: target_name = WSL
2020-08-26 22:10:08,493[INFO]: preferred_theme = Adwaita
2020-08-26 22:10:08,493[INFO]: alternative_theme = ('Papirus', 'Humanity', 'elementary-xfce')
2020-08-26 22:10:08,493[INFO]: jinja_template_batch = None
2020-08-26 22:10:08,493[INFO]: jinja_template_shell = None
2020-08-26 22:10:08,493[INFO]: rc_file = /home/haosmos/.zshrc
2020-08-26 22:10:08,493[INFO]: has_imagemagick = True
2020-08-26 22:10:08,493[INFO]: has_cairosvg = True
2020-08-26 22:10:08,494[INFO]: launch_directory = /home/haosmos
2020-08-26 22:10:08,528[INFO]: install_directory = /mnt/c/Users/Haosmos/.config/wsl-windows-toolbar-launcher/menus/WSL
2020-08-26 22:10:08,528[INFO]: metadata_directory = /mnt/c/Users/Haosmos/.config/wsl-windows-toolbar-launcher/metadata/WSL
2020-08-26 22:10:08,528[INFO]: For full list of options available, call script again with --help
2020-08-26 22:10:08,528[INFO]: This script will write to the above locations if it can, but giving final chance to chicken out.
Press <enter> to continue or ctrl+c to abort.

Is it good or bad? 🤔

[fquinner]

Hit enter and let fly

[haosmos]

Hit enter and let fly

I pressed "Enter" and the process of creating the menu began.

2020-08-26 22:15:07,990[INFO]: Finished creating 157 shortcuts!
2020-08-26 22:15:07,991[INFO]: Before raising an issue, make sure you have Xming / X410 etc set up in your .bashrc.
2020-08-26 22:15:07,991[INFO]: Right click on the toolbar, then select Toolbars -> New toolbar... and select the directory '/mnt/c/Users/Haosmos/.config/wsl-windows-toolbar-launcher/menus/WSL'.

I created a new menu and ... applications from wsl-toolbar do not run again with the VcXsrv server running 😭

[haosmos]

Something strange: I can run the ranger and htop applications via the wsl-toolbar - but no other applications.

https://yadi.sk/i/94ML6-YkfWd9dw

[fquinner]

Yeah that's expected they run in a terminal so they don't use X11. Guess its time to run the script again with option number 2...

[haosmos]

2. Using --jinja-template-shell /path/to/template.j2 where template.j2 is a file with these contents:

— I cannot find this file: I am using fzf to search and it cannot find this file.

Maybe the reason is that when installing wsl-toolbar, the following message was displayed:

🤔

[fquinner]

You need to create it as I mentioned above with those contents and pass it to the script on the command line

[haosmos]

You need to create it as I mentioned above with those contents and pass it to the script on the command line

— If the shell shows that the command cannot be executed, then I need to download this utility - https://pypi.org/project/j2cli/?

[fquinner]

You haven't passed it to the script... its wsl-windows-toolbar with that argument after. The script will parse the template you don't need j2cli.

[haosmos]

You haven't passed it to the script... its wsl-windows-toolbar with that argument after. The script will parse the template you don't need j2cli.

— I did:

wsl-windows-toolbar -J /home/haosmos/template.j2

After that, the menu creation process was started again and after creating the toolbar, the applications are not started again.

There is probably something wrong with the wsl, which prevents your script from being installed and working properly.

I think it's better if I stop torturing you with my dilettantish questions. Please forgive me for taking up a lot of your time.

Thank you for your help, anyway!