fish_config web url unreachable under WSL

[mqudsi]

When fish_config is run under WSL, the URL is inaccessible (hangs indefinitely) both from within WSL and from a web browser running in the Win32 environment.

I'm not a pythonista by any means, but I'm willing to debug the issue if anyone has some pointers on where to start. I'm not sure what the correct approach would be to capturing packets here, I'd have to dig into the WSL networking implementation to see how localhost is exposed and how packets can be intercepted (WinPCap doesn't capture localhost, and even if it did, I'm not sure how that plays with WSL).

As a quick test to see if it's a problem with binding to a port from WSL, I ran the following:

nc.traditional -l -p 5432 -c 'echo -e "HTTP/1.1 200 OK\r\n$(date)\r\n\r\n";echo "<p>Hello world.</p>"'

But that works fine when accessed from a web browser in Windows.

[zanchey]

It might be worth starting with the basics - does it get as far as opening the socket?

There's a select-based mainloop - I wonder if there's a problem with the sys.stdin reference there. You could try removing it and seeing if that helps, though then you have to kill the process manually.

[JBanks]

@mqudsi, I think this issue can be closed, everything works fine on my WSL setup. Could have been fixed since the creator's update.

I performed the following:

Terminal

[redacted]@[redacted] ~> fish_config

File Explorer

Open the following file:

C:\Users\[redacted]\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\home\[redacted]\.cache\fish\web_config-NVW4TI.html

[mqudsi]

@JBanks thanks for trying it out. It's still broken for me on 16299 and 17133 on two different machines, though.

What version of fish is this, and do you know if it is executing under python2 or python3?

[JBanks]

Everything I'm using is straight from the default apt repositories for Ubuntu on windows:

Fish: 2.2.0
Windows: 16299

Output from /usr/bin/python:

Python 2.7.12 (default, Dec  4 2017, 14:50:18)
[GCC 5.4.0 20160609] on linux2

[JBanks]

@mqudsi
I updated my version of fish, and fish_config stopped working.

sudo apt-add-repository ppa:fish-shell/release-2
sudo apt update
sudo apt upgrade

It's now running on python3:

It still opens the port to connect to, but it won't respond to any communication:

After running the script, copy the URL, and then close the terminal browser q and then y Once the terminal browser is closed, you should be able to open the webpage.

It has to do with this code block from from 2.7.1:

# Disable CLI web browsers
term = os.environ.pop('TERM', None)
if term:
    os.environ['TERM'] = term

and 2.2.0:

# Disable CLI web browsers
term = os.environ.pop('TERM', None)
import webbrowser
if term:
    os.environ['TERM'] = term

The code removes the TERM environment variable in order to set up the webbrowser library to disallow CLI browsers (most don't allow the use of javascript, so I suspect this is why).

>>> import os
>>> os.environ['TERM']
'xterm-256color'
>>> os.environ.pop('TERM', None)
'xterm-256color'
>>> os.environ['TERM']
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/os.py", line 725, in __getitem__
    raise KeyError(key) from None
KeyError: 'TERM'

I've tried lynx and w3m from both the current console (as the default browser launched from the python script), and a separate console. From the same console, both fail. From a separate console, they are both successful in connecting (as long as you close the browser as stated above). This is likely from the script not being threaded. I think the python script waits for the browser to close before accepting connections which causes the system to show the open port, while not responding to the clients.

@krader1961, it looks like you made this change on 10 November 2016. Can we look at making the OOB import lint friendly, or should we just comment the line so that any future linters know what's going on? If you don't mind, I'd like to make the commit so that this can be my first OSS contribution, I just want to make sure that I follow your code standards.

[zanchey]

I think the python script waits for the browser to close before accepting connections which causes the system to show the open port, while not responding to the clients.

More or less. See #1132.

I've fixed this in 61ab3ae but I'm not certain that it will solve the issue - @mqudsi ?

[mqudsi]

@zanchey still not working here. w3m is (still) launched though reading from the filesystem and not :8080 and navigating either in w3m or in the browser to the displayed URL hangs indefinitely.

after running killall www-browser; killall w3m; the webserver is unblocked and navigating to :8080finally responds, but going tohttp://localhost:8000/304c59909b351a4c7767cdb55f66c3ae` redirects to / which returns an HTTP 403.

[mqudsi]

I technically fixed this issue in 99ecaec by launching the URL in the (graphical) system web browser under WSL (in a separate process), but the underlying issue persists. A command line browser must be started in a separate terminal (not possible in a real terminal) or fish_config must be backgrounded (but not suspended). Not sure if I should close this. Do we have another issue tracking #1132?

[musm]

I have the same problem. Fish 2.7.1 is there a workaround?

[mqudsi]

Try suspending the fish_config process with ctrl-z.

[mqudsi]

@zanchey it's funny, your workaround kicked in for me on a different machine today.

I think between that and the wsl fix, we're good here for 3.0.

[imthenachoman]

I am having this problem too but cannot figure out how to fix it based on the comments here. I can find file in C:\Users\user\AppData\Local\Packages\TheDebianProject.DebianGNULinux_76v4gfsz19hv4\LocalState\rootfs\home\nacho\.cache\fish but opening it tries to redirect to localhost which obviously won't work. What to do?

[mqudsi]

@imthenachoman what version of fish?

[imthenachoman]

@imthenachoman what version of fish?

The latest - 3.0.0.

But I was able to get it working. Not sure what fixed it but after a reboot I was able to open the browser. The problem is now that the settings don't save. I change the prompt but it doesn't do anything.

Is there anyway to use the web configuration to save the settings in a file I can copy to fish config directory?

[ridiculousfish]

@imthenachoman

1. Are you clicking the Set Prompt button? (Selecting the prompt only previews it)

2. The function autoloading isn't super good about noticing changed files. If you set the prompt and then open a new terminal window, is the prompt still not set?

fish_config just runs by executing fish commands. We should have a mode to print the commands it runs (but we don't).

[imthenachoman]

1. Yes
2. Not set.

[llagerlof]

The problem is now that the settings don't save. I change the prompt but it doesn't do anything.

Now, in version 3.0.2 (ubuntu on wsl), I am having this issue too. Maybe some issue with the path used by fish?

Below is the output by fish_config:

lawrence@myubuntuwsl /home> fish_config
Web config started at file:///home/lawrence/.cache/fish/web_config-OSGO09.html
Hit ENTER to stop.
'\\wsl$\Ubuntu\usr\local\share\fish\tools\web_config'
CMD.EXE was started using the above path as current directory.
No support for UNC path. Using Windows directory.
$ set -L
$ set -U fish_color_normal normal
$ set -U fish_color_command 164CC9
$ set -U fish_color_quote 4C3499
$ set -U fish_color_redirection 248E8E
$ set -U fish_color_end 02BDBD
$ set -U fish_color_error 9177E5
$ set -U fish_color_param 4319CC
$ set -U fish_color_comment 007B7B
$ set -U fish_color_match --background=brblue
$ set -U fish_color_selection white --bold --background=brblack
$ set -U fish_color_search_match bryellow --background=brblack
$ set -U fish_color_history_current --bold
$ set -U fish_color_operator 00a6b2
$ set -U fish_color_escape 00a6b2
$ set -U fish_color_cwd green
$ set -U fish_color_cwd_root red
$ set -U fish_color_valid_path --underline
$ set -U fish_color_autosuggestion 7596E4
$ set -U fish_color_user brgreen
$ set -U fish_color_host normal
$ set -U fish_color_cancel -r
$ set -U fish_pager_color_completion normal
$ set -U fish_pager_color_description B3A06D yellow
$ set -U fish_pager_color_prefix white --bold --underline
$ set -U fish_pager_color_progress brwhite --background=cyan

[jarcane]

The created HTML file is not accessible outside of WSL anymore after the current version of WSL2, as the filesystem is hidden in a virtual disk image.

Instead what I had to do was:

• exit WSL
• run wsl -shutdown <- this is because of a bug in WSL2 that doesn't open up localhost ports to Windows properly
• start WSL again
• start fish_config
• open the file:/// url in w3m
• copy the localhost URL given on that page o
• open that URL in your Windows browser of choice
• voila, fish_config interface appears and works

Kind of a pain in the ass, but this doesn't really seem like Fish's fault, just the weirdness of WSL. God only knows what I'm gonna deal with when I install OMF ... 😉

[6A61736F6E206E61646572]

I don't have WSL2 so cannot check - what's the final URL that you end up using look like?

On WSL1 using fish 3.1b it is file://wsl%24/Ubuntu/usr/local/share/doc/fish/index.html

[jarcane]

the file:/// URL is a local path to within the Linux filesystem, specifically somewhere in my Linux home directory, /home/jarcane/...etc., which of course doesn't work

The localhost URL is the usual one, and looks like this or similar: http://localhost:8000/304c59909b351a4c7767cdb55f66c3ae%60

[6A61736F6E206E61646572]

Can look into this once WSL2 comes out of the insider program. Might be a while away though...

[Gorthog]

Funnily enough, I get a powershell error:

Start : This command cannot be run due to the error: The system cannot find the file specified.
At line:1 char:1
+ Start "file:///home/user/.cache/fish/web_config-MK7R7T.html"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

as a workaround for now what worked for me:

cd ~/.cache/fish
explorer.exe *.html

[Rhahkeem]

Should there be another issue for tracking this? I just came here because i have the same problem with wsl2

[Rhahkeem]

#4299 (comment)

was the fix for me for wsl2 in case anyone came here for the same thing

[zanchey]

Yes, if it's an ongoing issue with WSL2 (which I believe is still in beta?) you could open another issue; you could also ask Microsoft as I imagine there are other programs relying on this behaviour.

[Dunky13]

I tried the suggestion from #4299, but for me I'm getting Connection Refused errors.

[zanchey]

@Dunky13 if you're still having this issue, can you open another issue?

[Dunky13]

I don't know. I've since switched to Linux, because I was having all sorts of issues with wsl, not just fish. So I can't reproduce it anymore. I do remember that from time to time it would work, other times it wouldn't. Depending on the "mood" my PC booted into

[souravrax]

the file:/// URL is a local path to within the Linux filesystem, specifically somewhere in my Linux home directory, /home/jarcane/...etc., which of course doesn't work

The localhost URL is the usual one, and looks like this or similar: http://localhost:8000/304c59909b351a4c7767cdb55f66c3ae%60

I solved this issue by doing the following:

1. Opened the webconfig.py file located in /usr/share/fish/tools/web_config/

2. Added write permission to the webconfig.py file by running chmod 777 webconfig.py

3. Changed the value of fileurl variable
   from "file:///" + f.name" to "file://wsl%24/Ubuntu" + f.name
   

4. Change the file's permission back to its original state by running chmod 644 webconfig.py

5. Now it's working the way it should ✌✨

[stuckinforloop]

the file:/// URL is a local path to within the Linux filesystem, specifically somewhere in my Linux home directory, /home/jarcane/...etc., which of course doesn't work
The localhost URL is the usual one, and looks like this or similar: http://localhost:8000/304c59909b351a4c7767cdb55f66c3ae%60

I solved this issue by doing the following:

1. Opened the webconfig.py file located in /usr/share/fish/tools/web_config/
2. Added write permission to the webconfig.py file by running chmod 777 webconfig.py
3. Changed the value of fileurl variable
   from "file:///" + f.name" to "file://wsl%24/Ubuntu" + f.name
   
4. Change the file's permission back to its original state by running chmod 644 webconfig.py
5. Now it's working the way it should ✌✨

For those, who are still having problem like how I had after going through this process, just make sure to check the correct path of your file. For instance, mine was wsl%24/Ubuntu-20.04 instead wsl%24/Ubuntu.

To check for your path, just run 'help' and see where the documentation web page is pointing to.

[duckness]

If the above solutions don't work, your WSL2 distro might not have the latest version of fish. A fix that worked for me was to fix the wsl detection of webconfig.py. Edit your /usr/share/fish/tools/web_config/webconfig.py to be the same as

fish-shell/share/tools/web_config/webconfig.py

Lines 45 to 52 in ee84223

	def is_wsl():
	""" Return whether we are running under the Windows Subsystem for Linux """
	if "linux" in platform.system().lower() and os.access("/proc/version", os.R_OK):
	with open("/proc/version", "r") as f:
	# Find 'Microsoft' for wsl1 and 'microsoft' for wsl2
	if "microsoft" in f.read().lower():
	return True
	return False

In particular, "microsoft" instead of "Microsoft"

[faho]

Why is this ticket closed ?

Because it was fixed for wsl1. WSL2 (which AFAICT wasn't even released when this bug was closed) is a different bug that is fixed in master (by #7027) and will be released with the next release.

[faho]

Have a look at this.

Have a look at #7027