Wttr.in: Unable to show weather data on Windows console
The console is not able to display data returned by curl wttr.in. It's all garbled. I know it's a Windows problem but do you have any suggestions on how can I make it work.
I even tried an external console emulator, ConEmu. No luck there too.
aviaryan
All 48 comments
Do you have a powershell?
It works perfectly there
chubin
on 24 Feb 2016
powershell seems to give a different output. It looks like it is analyzing the webpage.
StatusCode : 200
StatusDescription : OK
Content : <html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<link rel="stylesheet" type="text/css" href="/files/style.css" />
<link rel="stylesheet" type="text/css" href="/files...
RawContent : HTTP/1.1 200 OK
Connection: keep-alive
Content-Length: 28676
Content-Type: text/html; charset=utf-8
Date: Thu, 25 Feb 2016 05:02:38 GMT
Server: nginx/1.2.6
<html>
<head>
<meta http-equiv="Cont...
Forms : {}
Headers : {[Connection, keep-alive], [Content-Length, 28676], [Content-Type, text/html; charset=utf-8],
[Date, Thu, 25 Feb 2016 05:02:38 GMT]...}
Images : {}
InputFields : {}
Links : {@{innerHTML=Follow @igor_chubin; innerText=Follow @igor_chubin; outerHTML=<A
class=twitter-follow-button href="https://twitter.com/igor_chubin" data-button="grey"
data-show-count="false">Follow @igor_chubin</A>; outerText=Follow @igor_chubin; tagName=A;
class=twitter-follow-button; href=https://twitter.com/igor_chubin; data-button=grey;
data-show-count=false}, @{innerHTML=wttr.in; innerText=wttr.in; outerHTML=<A aria-label="Star
chubin/wttr.in on GitHub" class=github-button href="https://github.com/chubin/wttr.in"
data-icon="octicon-star" data-count-href="/chubin/wttr.in/stargazers"
data-count-api="/repos/chubin/wttr.in#stargazers_count" data-count-aria-label="# stargazers on
GitHub">wttr.in</A>; outerText=wttr.in; tagName=A; aria-label=Star chubin/wttr.in on GitHub;
class=github-button; href=https://github.com/chubin/wttr.in; data-icon=octicon-star;
data-count-href=/chubin/wttr.in/stargazers; data-count-api=/repos/chubin/wttr.in#stargazers_count;
data-count-aria-label=# stargazers on GitHub}, @{innerHTML=wego; innerText=wego; outerHTML=<A
aria-label="Star schachmat/wego on GitHub" class=github-button
href="https://github.com/schachmat/wego" data-icon="octicon-star"
data-count-href="/schachmat/wego/stargazers"
data-count-api="/repos/schachmat/wego#stargazers_count" data-count-aria-label="# stargazers on
GitHub">wego</A>; outerText=wego; tagName=A; aria-label=Star schachmat/wego on GitHub;
class=github-button; href=https://github.com/schachmat/wego; data-icon=octicon-star;
data-count-href=/schachmat/wego/stargazers; data-count-api=/repos/schachmat/wego#stargazers_count;
data-count-aria-label=# stargazers on GitHub}}
ParsedHtml : System.__ComObject
RawContentLength : 28676
Replacing curl with curl.exe fixed that issue. But the report returned is still garbled.
Weather for City: Oymyakon, Russia
Freezing fog
←[38;5;251m _ - _ - _ - ←[0m ←[38;5;021m-34←[0m ΓÇô ←[38;5;021m-33←[0m ┬░C←[0m
←[38;5;251m _ - _ - _ ←[0m ←[1mΓåù←[0m ←[38;5;082m2←[0m km/h←[0m
←[38;5;251m _ - _ - _ - ←[0m 0 km←[0m
0.0 mm←[0m
ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
I have the same trouble as well. Using a monospaced font (Consolas) with UTF-8 (65001 code-page) on ConEmu + Cmder.
babhishek21
on 3 Apr 2016
The same problem. Powreshell, conemu or cmd.exe all the same. Used source code pro.
majkinetor
on 10 Apr 2016
People on Reddit found solution:
$(Invoke-WebRequest http://wttr.in ).ParsedHtml.body.outerText
We should (at least) document it in README.md. Some good examples are appreciated.
chubin
on 3 Sep 2017
(Invoke-WebRequest "http://wttr.in" -UserAgent curl -UseBasicParsing).content
alexsuslin
on 6 Apr 2018
@alexsuslin does it work for you? Could you do a screenshot?
chubin
on 6 Apr 2018
majkinetor
on 6 Apr 2018
Funny enough, I am from Minsk - and it shows Vietnam =)
-BasicParsing is needed when there is no initial Internet Exporer setup. That can be omitted by disabling in group policy or launch IE and proceed with default setup.
Also, there is a nice wrapper: https://gist.github.com/9999years/672f06ca425f90ef1f1c946804d1848e
P.S. just "curl" is an alias in powershell command Invoke-WebRequest
P.P.S. (curl wttr.in -UserAgent curl).Content
alexsuslin
on 6 Apr 2018
@alexsuslin thank you for the screenshots! Regarding Vietnam, it's a known bug, for the moment it shows weather for the city of NOT (that located in Vietnam) for the locations that are "NOT found" .
chubin
on 7 Apr 2018
@majkinetor You have no colors in the output (contrary to @alexsuslin ). Was it your intention?
chubin
on 7 Apr 2018
Nah. I didnt know it was colored
majkinetor
on 7 Apr 2018
My 2 cents:
@doskey weather=powershell $w = (curl wttr.in -UserAgent curl).Content; echo `r $w.Substring(0, $w.lastIndexOf($([char]0x2518)) + 1).replace($([char]0x2196), $([char]0x005C)).replace($([char]0x2197), $([char]0x002F)).replace($([char]0x2198), $([char]0x005C)).replace($([char]0x2199), $([char]0x002F));
u01jmg3
on 17 Jul 2018
Just to let you guys know, that isn't a bug in wttr.in, but a limitation of the current Win32 version of curl.
Basically the Windows 10 console starts without VT processing enabled for backward compatibility.
The current Win32 version of curl.exe (shipping in Win10 1809) doesn't change the configuration of the console, so it inherits whichever mode was set by another process attached to the same console before it.
It seems cmd.exe and PowerShell both unset the VT-processing flag before launching external utilities, probably to accommodate for backward compatibility again, assuming if an utility expects VT processing, it will set the flag itself before outputting VT markup.
Launching curl.exe from a shell that leaves the VT-processing flag on does result in the expected colorful result, but that means you'd need an intermediate launcher when using it from cmd.exe or PowerShell.
The only proper fix is for curl.exe to enable VT-processing.
More details if you want : https://github.com/Microsoft/console/issues/216
wttr.in works properly when ENABLE_VIRTUAL_TERMINAL_PROCESSING is set, except for diagonal wind directions arrows that use a glyph not available in the standard console fonts (Consolas and Lucida Console).
PhMajerus
on 19 Mar 2019
Turns out that you can enable the ENABLE_VIRTUAL_TERMINAL_INPUT flag with chcp 65001 | start /wait /b curl http://wttr.in. See the comment here https://github.com/microsoft/Terminal/issues/51#issuecomment-386302437
You can also enable it by calling the SetConsoleMode win32 API directly from PowerShell. Or enable it globally by setting the default codepage to 65001, or by creating a DWORD named VirtualTerminalLevel in the registry key HKEY_CURRENT_USER\Console
Unfortunately the diagonal arrows are displayed as � on the default conhost.exe. It's bettter on the new Windows Terminal, but the diagonal arrows are now double width (https://github.com/microsoft/Terminal/issues/714), breaking the layout. Here's the comparison
IMHO all arrows should take 2 cells instead of 1 so that they look prettier
phuclv90
on 12 May 2019
The command from @majkinetor gives a monochrome output, while the one from @alexsuslin prints the colors nicely for me. Note that later MS did include the real curl to Windows 10 so you can use curl.exe in powershell
Funny that I'm from Vietnam and I've never seen an airport with IATA code NOT. Just checked and it's the Marin County Airport from the USA
phuclv90
on 12 May 2019
@phuclv90 The problem is a little bit broader than you probably think.
It is not only Windows, where the arrows (and the lightning symbols) may have bigger width than other characters. It depends on the environment: the font, the terminal emulator/the browser etc.
See for example #34 and #192.
The only possible two solutions that I see for the moment:
- To add an option to force ASCII symbols for wind directions (
>,<,v,^,/'',\,,,/,'\) - To pass in the option what characters have what width in your environment, something like
w=6(bitmask)
Probably we should implement both of them.
And regarding NOT, it was not NOT what @alexsuslin had, it was Ban Not, and I think there should be a location with such name in Vietnam (I did not check), it was a bug in the geolocation, and it returned something like Not found and it was somehow converted into this Not. But anyway, the problem was fixed long ago.
PS. The @u01jmg3 's workaround should work fine by the way
chubin
on 12 May 2019
Hey all. This issue is caused by the curl.exe built into Windows not enabling VT support by default.
I submitted a PR to curl in Sept 2018, but we've not yet pulled & rebuilt the inbox curl.exe to benefit from this and other improvements.
Issue #216 in the Terminal repo that I've just re-opened, and I am chasing this down internally, and hope that the next Windows 10 release includes an update curl.exe that allows us all to check the weather on Windows too :)
Will report back once we have a resolution.
bitcrazed
on 5 Oct 2019
@bitcrazed Thank you Rich for keeping us updated,
what about v2.wttr.in (curl v2.wttr.in)? Does it work as it should in the Terminal?
Or there some other problems with it?
For that, (1) emojis support (2) braille support is need. I am not sure, but as far as I remember, there were the Terminal users, who reported some problems with it, as I did prerelease of the v2.
chubin
on 6 Oct 2019
apolopena
on 20 Apr 2020
@apolopena What is this? Some related issues?
chubin
on 20 Apr 2020
I believe this is the roadmap for Windows 10 implementing the console fix @bitcrazed mentioned Oct 16th 2019. At the time of posting this the status was: Due by April 30, 2020 27% complete
apolopena
on 20 Apr 2020
@apolopena ah, ok, also this: https://twitter.com/richturn_ms/status/1248028376100560896
chubin
on 20 Apr 2020
@chubin, Awesome. I had a feeling from reading all the threads that there was a build out there with the fix in it. It also looks like eventually the fixed curl.exe will make it into an upcoming windows release/update.
apolopena
on 21 Apr 2020
@apolopena It is not only curl, but the terminal itself too. If I understand it right, it will be soon publicly available
chubin
on 21 Apr 2020
@chubin Do you mean terminal as in cmd.exe?
Until the fixes come out, this works great for me in Powershell:
(Invoke-WebRequest http://wttr.in/~Golden+Gate+Bridge?1 -UserAgent "curl" ).Content
And this in Cmder:
powershell (Invoke-WebRequest http://wttr.in/~Golden+Gate+Bridge?1 -UserAgent "curl" ).Content
apolopena
on 22 Apr 2020
@apolopena I suppose that you don't need -UserAgent "curl", it should work without it. Please test
chubin
on 23 Apr 2020
@chubin Both of these commands below output the entire html page:
(Invoke-WebRequest http://wttr.in/~Golden+Gate+Bridge?2).Content
(curl http://wttr.in/~Golden+Gate+Bridge?2).Content
I can only get the proper output (minus the diagonal wind directions) by adding -UserAgent "curl" to either of those two above commands.
I am on Windows 10.0.18362 Using Powershell 5.1.18362.752
apolopena
on 26 Apr 2020
@apolopena if curl is an alias of Invoke-WebRequest on your system then you must use curl.exe to call the curl binary, or just remove the alias completely. curl.exe http://wttr.in/~Golden+Gate+Bridge?2 will work without problem. curl.exe is the real binary from libcurl and is very different from theInvoke-WebRequest cmdlet
Do you mean terminal as in cmd.exe?
cmd.exe is a shell like powershell or bash, not terminal. On Windows the default terminal is conhost.exe. The rendering of the characters depend on the terminal and not the shell
phuclv90
on 26 Apr 2020
@apolopena I suppose that you don't need
-UserAgent "curl", it should work without it. Please test
Without -UserAgent "curl" I get the whole html with Invoke-WebRequest on my PC too.
Powershell 5.1.19613.1000, Windows 10 build 19613.1000
phuclv90
on 26 Apr 2020
@phuclv90 @apolopena Thank you for testing and reporting.
It is strange that it behaves this way, because after #428 is merged,
PowerShell must be seen as a terminal-oriented client,
and so the response should be in the ANSI format.
wttr.in users reported that the fix by @Jaykul worked.
I suppose that it depends on the PowerShell version, and some
older PowerShell versions don't have any information about PowerShell in the agent string.
@Jaykul used PowerShell 7.x for the tests, and you (@phuclv90 @apolopena)
are using some pretty old PowerShell as far as I can judge.
Could you please check if my assumption is correct, and your powershell
does not expose itself as PowerShell, and it is not our bug?
(in such case you could just for ANSI output with the A option, instead of faking the user agent:
(curl http://wttr.in/~Golden+Gate+Bridge?2A).Content)
chubin
on 26 Apr 2020
@chubin PowerShell 6.0 and 7.0 are PowerShell Core and is only available with .NET Core which is not installed by default. I'm on the fast insider channel of Windows 10 and have the latest default version. You can see that its version is the same as Windows build version
phuclv90
on 26 Apr 2020
@phuclv90 Yes, you are right, I see it now, but the question still remains why does it work for PowerShell 7.0.0 like it should, but not for PowerShell 5.0.
I've checked the logs, and I see that PowerShell 5.0 exposes itself in the user-agent header too,
though as WindowsPowerShell and not as PowerShell, but it should not be the problem.
"Mozilla/5.0 (Windows NT; Windows NT 10.0; en-IN) WindowsPowerShell/5.1.18362.628"
"Mozilla/5.0 (Windows NT 10.0; Microsoft Windows 10.0.18363; en-US) PowerShell/7.0.0"
I think I have found the problem. Could you please test it again? (without overriding user-agent and without the ?A option)
chubin
on 26 Apr 2020
I've just tried and (Invoke-WebRequest http://wttr.in/~Golden+Gate+Bridge).Content still doesn't work. None of the below works either
(Invoke-WebRequest http://wttr.in/~Golden+Gate+Bridge -UserAgent "Mozilla/5.0 (Windows NT; Windows NT 10.0; en-IN) WindowsPowerShell/5.1.18362.628").Content
(Invoke-WebRequest http://wttr.in/~Golden+Gate+Bridge -UserAgent "Mozilla/5.0 (Windows NT 10.0; Microsoft Windows 10.0.18363; en-US) PowerShell/7.0.0").Content
@phuclv90 Sorry, it was my fault; please try now
chubin
on 27 Apr 2020
@chubin It's working now
phuclv90
on 27 Apr 2020
@chubin Yes it's working now.
(curl http://wttr.in/~Golden+Gate+Bridge?2).Content now outputs as expected.
What did you change?
apolopena
on 27 Apr 2020
@apolopena user-agents here:
https://github.com/chubin/wttr.in/commit/7801bd04684dd2739942ef4ad186b59e9dee45f7
must be in lower case
chubin
on 27 Apr 2020
@chubin, @phuclv90 Great, it's all sorted out now.
Do you think it would be useful and in-scope to add a section to the readme regarding caveats one would encounter regarding using different terminals that have different default codepages and output encodings such as Powershell and Cmder? And possibly define the usage of "curl/Invoke-WebRequest", and "curl.exe" in Powershell.
Currently the examples just use curl and assume Powershell is not used which is fine, however if a Powershell or Cmder user tries the examples from the readme they will get garbage characters by default.
Lastly, until the issue is properly addressed, giving out a workaround for swapping out the double wide wind direction characters might be a nice touch.
apolopena
on 27 Apr 2020
Upon further thought what I suggested above would just end up being a suggestion of use for windows users so probably shouldnt be added.
apolopena
on 28 Apr 2020
@apolopena I think it is a good idea to add a small section for Windows users. There are several interesting topics that could be clarified there. Alone the topic that curl in windows is not the same as curl.exe worth such a section
chubin
on 28 Apr 2020
@chubin yeah I would be happy to add what ended up working for me best; All via Powershell (due to the curl issue): either VSCode Integrated Terminal using Cmder or Windows Terminal (preview) with or without Cmder. I finally got it all working with the proper glyphs, no garbage and no need to swap symbols or change fonts. I am sure there are plenty of way to do it though.
apolopena
on 29 Apr 2020
@apolopena It would be really great if you could write down all your experiences, and give advises to the wttr.in windows users.
I mentioned in the README file (at the beginning) that PowerShell is also supported, and gave a small example of a command, that can be used to access the service, but it is not enough to cover all the details.
Feel free to add a new section to the README file (I think that just after the "Internationalization and Localization" and before the Installation is the best place for the moment); just add it and send a pull request to me
chubin
on 2 May 2020
apolopena
on 9 May 2020
Thank you @apolopena (merged). Regarding the diagonal wind direction issue:
It would be possible to integrate the solution as proposed by @u01jmg3 in wttr.in itself,
but the question is how we can distinguis then between ↖ and ↘?
'\ and \, perhaps?
chubin
on 9 May 2020
Yeah there might not be anything better than using two characters which is a bit cryptic, in that case we might want to think about using NE, NW, SE, SW but that is not ideal either due to localization. Also accurately detecting when the swap needs to happen might be tricky as we don't want false positives. Maybe just query options for english abbreviations and ASCII equivalents is the way to go.
Current swaps are:
0x2196 = ↖ (north west arrow) swap to 0x005C = \ (reverse solidus)
0x2197 = ↗ (north east arrow) swap to 0x002F = / (solidus)
0x2198 = ↘ (south east arrow) swap to 0x005C = \ (reverse solidus)
0x2199 = ↙ (south west arrow) swap to 0x002F = / (solidus)
apolopena
on 9 May 2020
Related issues
ruijramos
·
7Comments
532910
·
7Comments
sleeperzjf
·
7Comments
m0lmk
·
5Comments
chubin
·
7Comments
Most helpful comment
People on Reddit found solution: