search

cpbotha / xdg-open-wsl

xdg-open replacement for WSL that opens files and links using Windows apps.
BSD 3-Clause "New" or "Revised" License
159 stars 12 forks source link

when opening browser getting text output message #5

Open pcause opened 3 years ago

pcause commented 3 years ago

if I do:

xdg-open 'https://google.com'

I get a message:

CMD.EXE was started with the above path as current directory UNC paths are not supported. Defaulting to windows directory.

The directory is shows is \wsl\home\me\some-subdirectory - basically whatever directory i am in when it executes.

Log just shows running /mnt/c/windows/system32/cmd.exe /c start https://google.com

I am trying to run this from a curses based python app the the output messes up the screen.

[added] if i enter the cmd.exe /s start https://google.com in bash in wsl I get the same. so the message is coming from cmd.exe. wonder if powershell would handle better

[added] powershell.exe start https://google.com gives no messages

[added] sorry, changed the script to use /mnt/c/Windows/System32/WindowsPowershell/v1.0/powershell.exe and all is file. start /c start url

cpbotha commented 2 years ago

I'm glad you could solve it with powershell!

I just tested, and although it does not spam the same error message, opening links with powershell does take a measurable time longer than opening them with cmd.exe

explorer.exe also works, but in the past there have been URLs that it failed to open while cmd.exe /c start has been pretty reliable.

One could also consider going directly for the Windows FileProtocolHandler, see https://stackoverflow.com/a/49115945/532513

For now I'm going to keep the cmd.exe solution, but I'm also keeping this issue open in case more people run into it.

ashb commented 1 year ago

It's probably a bad idea in case something goes wrong, but I've hacked my local copy to have this for the URL paths:

        subprocess.run(sp_run_arg, stderr=subprocess.DEVNULL)