I'm a long time Cmder user and for idiosyncratic reasons I've historically run the 32-bit version of cmd.exe, so I didn't encounter this problem until just now.
I was building dotnet/wpf just now and noticed that it had trouble building correctly.
I debugged it down to these lines that fail to initialize the MSBuild property $(Architecture) correctly (it's initialized to 64 instead of x64), which in turn lead to my (dev) build failures in dotnet/wpf.
<Architecture Condition="'$(Platform)'=='x64' or '$(Platform)'=='x86' or '$(Platform)'=='arm' or '$(Platform)'=='arm64'">$(Platform)</Architecture>
<Architecture Condition="'$(Platform)'=='Win32'">x86</Architecture>
<Architecture Condition="'$(Architecture)'==''">x64</Architecture>
Ultimately, this seems to the what caused my troubles, where %architecture% is (seemingly) set for script-local use, but the environment-variable ultimately leaks out of the script:
I have two suggestions:
setlocal at the top of the batch file wherever it makes sense. I realize that the 'fix' may not be as simple as adding a one-line change, since some env-vars might be exported deliberately, whereas others might be leaking merely as a side-effect.x86, x64, arm, arm64 etc. for architecture (instead of 86, 64 etc. ).RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4