Unable to open applications from toolbar

[mattcobley]

Hi,

I recently installed the toolbar successfully, and am running Xming with the default setup on Windows 10 19.09. I'm running Ubuntu 18.04 on WSL1 as well, and I've installed Gnome via sudo apt install ubuntu-desktop.

When I first installed the toolbar I was able to open the Files application (Nautilus) without any trouble, but then found that nothing happened trying to open some others such as Firefox, Transmission etc. After some clicking around I think LibreOffice Draw opened for me as well but now today nothing is opening.

I went through the steps that you've recommended. I've got DISPLAY set to localhost:0.0, have disabled the public blocks on XMing in the firewall and have added a rule for TCP port 6000 in from the WSL subnet.

When I run the following commands they successfully open each application every time, they just don't open from the toolbar:

wsl.exe -d Ubuntu -u mattc -- source ~/.bashrc ; env; firefox
wsl.exe -d Ubuntu -u mattc -- source ~/.bashrc ; env; xterm
wsl.exe -d Ubuntu -u mattc -- source ~/.bashrc ; env; nautilus

Obviously happy to provide more information - just let me know which logs you want and where I can find them and I'll happy provide them.

[fquinner]

Erm, yeah that's a bit weird. Nothing gets logged atm, but the script execution path looks like

lnk -> vbscript -> bat -> wsl bash -> app

At the time that the documentation was written, it was simply lnk -> app so that may not be the best advice with the latest version but thanks for checking :).

Instead try executing the wsl bash script directly to begin with and see if that works. First try it from within a WSL environment e.g.:

"/c/Users/<your-user>/.config/wsl-windows-toolbar-launcher/metadata/WSL/Accessories/About Xfce.sh"

Then try launching with wsl from a cmd.exe shell (not powershell etc):

C:\Windows\System32\wsl.exe -d Ubuntu -u <your-user> -- "/c/Users/<your-user>/.config/wsl-windows-toolbar-launcher/metadata/WSL/Accessories/About Xfce.sh"

I'm guessing one or both of those will fail since there's not much else can physically go wrong.

[mattcobley]

Thanks for getting back so quickly. Strangely, both of the suggestions work for me! I did have to modify the second command since my WSL user has a slightly different username than my Windows user, but I tried Files.sh in both scenarios and it works. Unfortunately the toolbar still doesn't. Anything else I can get for you that might help?

[fquinner]

Erm, yeah that was unexpected... going up one level you could try running the batch file from cmd.exe, e.g:

"C:\Users\fquinn\.config\wsl-windows-toolbar-launcher\metadata\WSL\Accessories\About Xfce.bat"

And if that works, then try running it from vbscript (all that script does is hide the terminal while launching the terminal):

C:\WINDOWS\system32\wscript.exe "C:\Users\fquinn\.config\wsl-windows-toolbar-launcher\metadata\WSL\silent-launcher.vbs" "C:\Users\fquinn\.config\wsl-windows-toolbar-launcher\metadata\WSL\Accessories\About Xfce.bat"

If you get that far, you're literally running what the shortcut should be running, to check right click on the entry in the toolbar, go to properties and check the target matches that last command. Then try copying and pasting that into a cmd.exe terminal and I guess check if that works?

[mattcobley]

Thanks, just tried running the batch file and that doesn't seem to do anything. Interestingly the previous CMD command doesn't work either now - C:\Windows\System32\wsl.exe -d Ubuntu -u <your-user> -- "/c/Users/<your-user>/.config/wsl-windows-toolbar-launcher/metadata/WSL/Accessories/About Xfce.sh"

[fquinner]

Hate to be the turn it off and on again guy, but have you tried rebooting or running wsl --shutdown? I have seen some weird issues with trying to reuse stale TCP connections especially if it's a machine that you tend to suspend / resume etc. Also check with ps to check if your processes are actually launching, but are simply not forwarding to your X server.

[frankdfr96]

Erm, yeah that's a bit weird. Nothing gets logged atm, but the script execution path looks like

lnk -> vbscript -> bat -> wsl bash -> app

At the time that the documentation was written, it was simply lnk -> app so that may not be the best advice with the latest version but thanks for checking :).

Instead try executing the wsl bash script directly to begin with and see if that works. First try it from within a WSL environment e.g.:

"/c/Users/<your-user>/.config/wsl-windows-toolbar-launcher/metadata/WSL/Accessories/About Xfce.sh"

Then try launching with wsl from a cmd.exe shell (not powershell etc):

C:\Windows\System32\wsl.exe -d Ubuntu -u <your-user> -- "/c/Users/<your-user>/.config/wsl-windows-toolbar-launcher/metadata/WSL/Accessories/About Xfce.sh"

I'm guessing one or both of those will fail since there's not much else can physically go wrong.

I have the same problem as OP, except for me the second attempt here has never worked (no error messages from the command line, it just does nothing). I have checked with ps and the processes are not launching

(I am using vcxsrv)

[bobobobosu]

I have the same problem as OP, and I fixed it by replacing #!/bin/bash with #!/bin/bash -i in every .sh file in the metadata folder. Or, you can just comment out these lines in your .bashrc file to make it work. # If not running interactively, don't do anything case $- in *i*) ;; *) return;; esac

[frankdfr96]

I have the same problem as OP, and I fixed it by replacing #!/bin/bash with #!/bin/bash -i in every .sh file in the metadata folder. Or, you can just comment out these lines in your .bashrc file to make it work. # If not running interactively, don't do anything case $- in *i*) ;; *) return;; esac

This worked for me, thank you!

Would you mind quickly explaining what those lines do?

edit: nevermind, I looked it up and I have decided to not concern myself with it further

[mattcobley]

I have the same problem as OP, and I fixed it by replacing #!/bin/bash with #!/bin/bash -i in every .sh file in the metadata folder. Or, you can just comment out these lines in your .bashrc file to make it work. # If not running interactively, don't do anything case $- in *i*) ;; *) return;; esac

This worked for me, thank you!

Would you mind quickly explaining what those lines do?

edit: nevermind, I looked it up and I have decided to not concern myself with it further

Editing the sh files works for me, but I'd rather not do this as it obviously would be irritating to do every time if I reinstall the toolbar, e.g. if I install a new application. Annoyingly, changing my .bashrc and commenting out the early exit for non-interactive shells DOESN'T work for me - not sure if I could be doing something wrong, but my WSL Ubuntu install is vanilla - I've not done any previous customisation in that file or elsewhere.

[fquinner]

It must be some sort of early exit going on then. The .sh files are templates so its an easy fix then you can just re-run the script to update all of the files - I'll get a change together once I have tested it.

[fquinner]

Can you try again with the latest? Should be 0.5.4.

[mattcobley]

Works for me! Thanks!

[frankdfr96]

Works for me too!

It seems to somehow have changed the behavior of, say, /c/Users//.config/wsl-windows-toolbar-launcher/metadata/WSL/Accessories/files.sh & (used to work fine but doesn't do anything now, the process is running but nothing shows), but it's not really that important for this

[fquinner]

@frankdfr96 Yeah the launcher itself launches the application in the background, so if you run it with ampersand like that with bash running in interactive mode, it suspends the program until it's somewhere that you can interact with it.

If you run fg again it'll actually run fine, but yeah just need to not run it in background :).