[GH-ISSUE #18 ] I can run Linux GUI applications via terminal, but can&#39;t run via wsl-windows-toolbar. #17

Author

Owner

@fquinner commented on GitHub (Aug 22, 2020):

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.

@fquinner commented on GitHub (Aug 22, 2020): 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.

kerem commented

Author

Owner

@haosmos commented on GitHub (Aug 22, 2020):

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))

@haosmos commented on GitHub (Aug 22, 2020): 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](https://github.com/cascadium/wsl-windows-toolbar-launcher/blob/master/wsl-windows-toolbar-template.sh.j2?rgh-link-date=2020-08-22T09%3A17%3A42Z) 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))

kerem commented

Author

Owner

@fquinner commented on GitHub (Aug 22, 2020):

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?

@fquinner commented on GitHub (Aug 22, 2020): 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?

kerem commented

Author

Owner

@haosmos commented on GitHub (Aug 22, 2020):

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 commented on GitHub (Aug 22, 2020): > 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 ```

kerem commented

Author

Owner

@haosmos commented on GitHub (Aug 22, 2020):

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 😪

@haosmos commented on GitHub (Aug 22, 2020): > 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 😪

kerem commented

Author

Owner

@fquinner commented on GitHub (Aug 23, 2020):

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 commented on GitHub (Aug 23, 2020): 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.

kerem commented

Author

Owner

@fquinner commented on GitHub (Aug 24, 2020):

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.

@fquinner commented on GitHub (Aug 24, 2020): 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.

kerem commented

Author

Owner

@haosmos commented on GitHub (Aug 24, 2020):

@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).

@haosmos commented on GitHub (Aug 24, 2020): @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](https://github.com/DamionGans/ubuntu-wsl2-systemd-script/issues/40) 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).

kerem commented

Author

Owner

@fquinner commented on GitHub (Aug 24, 2020):

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.

@fquinner commented on GitHub (Aug 24, 2020): Hi @haosmos, Looking at the video, i see this in your `.bashrc`: ![image](https://user-images.githubusercontent.com/8431703/91086836-5fa5f680-e647-11ea-8130-9d12701b2c74.png) 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.

kerem commented

Author

Owner

@haosmos commented on GitHub (Aug 24, 2020):

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

😞😕

@haosmos commented on GitHub (Aug 24, 2020): 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 ``` 😞😕

kerem commented

Author

Owner

@fquinner commented on GitHub (Aug 25, 2020):

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 :))

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)
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 %}

@fquinner commented on GitHub (Aug 25, 2020): 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 %} ```

kerem commented

Author

Owner

@haosmos commented on GitHub (Aug 26, 2020):

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 :))

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)

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?

@haosmos commented on GitHub (Aug 26, 2020): > 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?

kerem commented

Author

Owner

@fquinner commented on GitHub (Aug 26, 2020):

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

@fquinner commented on GitHub (Aug 26, 2020): 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`

kerem commented

Author

Owner

@haosmos commented on GitHub (Aug 26, 2020):

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?

@haosmos commented on GitHub (Aug 26, 2020): > 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?

kerem commented

Author

Owner

@fquinner commented on GitHub (Aug 26, 2020):

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

@fquinner commented on GitHub (Aug 26, 2020): Its an argument to the script which generates the menu. E.g. `wsl-windows-toolbar --rc-file ~/.zshrc`

kerem commented

Author

Owner

@haosmos commented on GitHub (Aug 26, 2020):

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? 🤔

@haosmos commented on GitHub (Aug 26, 2020): > 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? 🤔

kerem commented

Author

Owner

@fquinner commented on GitHub (Aug 26, 2020):

Hit enter and let fly

@fquinner commented on GitHub (Aug 26, 2020): Hit enter and let fly

kerem commented

Author

Owner

@haosmos commented on GitHub (Aug 26, 2020):

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 commented on GitHub (Aug 26, 2020): > 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 😭

kerem commented

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

Author

Owner

@haosmos commented on GitHub (Aug 26, 2020):

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

@haosmos commented on GitHub (Aug 26, 2020): Something strange: I can run the ranger and htop applications via the wsl-toolbar - but no other applications. https://yadi.sk/i/94ML6-YkfWd9dw

kerem commented

Author

Owner

@fquinner commented on GitHub (Aug 26, 2020):

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

@fquinner commented on GitHub (Aug 26, 2020): 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...

kerem commented

Author

Owner

@haosmos commented on GitHub (Aug 26, 2020):

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:

🤔

@haosmos commented on GitHub (Aug 26, 2020): > 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: ![jinja_template_shell none](https://user-images.githubusercontent.com/30666874/91358166-05e62d80-e7fb-11ea-9c13-33986766dba1.jpg) 🤔

kerem commented

Author

Owner

@fquinner commented on GitHub (Aug 26, 2020):

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

@fquinner commented on GitHub (Aug 26, 2020): You need to create it as I mentioned above with those contents and pass it to the script on the command line

kerem commented

Author

Owner

@haosmos commented on GitHub (Aug 26, 2020):

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/?

@haosmos commented on GitHub (Aug 26, 2020): > 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/? ![--jinja-template-shell not found](https://user-images.githubusercontent.com/30666874/91360825-d38aff00-e7ff-11ea-9de8-eb3d8113d603.jpg)

kerem commented

Author

Owner

@fquinner commented on GitHub (Aug 26, 2020):

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.

@fquinner commented on GitHub (Aug 26, 2020): 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.

kerem commented