[Bug 46901] New: Path environment variable with nested variables is not expanded properly
https://bugs.winehq.org/show_bug.cgi?id=46901 Bug ID: 46901 Summary: Path environment variable with nested variables is not expanded properly Product: Wine Version: 4.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: scorpion8182(a)googlemail.com Distribution: --- Created attachment 63979 --> https://bugs.winehq.org/attachment.cgi?id=63979 Registry entries for HKCU\Environment\PATH I am trying to set up a crosscompile environment under Linux targeting MSVC. For that purpose I have copied the contents of a MS VC Build Tools and Win 10 SDK installation to two folders under /opt, basically. Afterwards I added entries to the PATH environment variable to construct the Pathes to the compiler, the includes and the libs. My target is to be able to invoke the tools (compiler, linker, resource compiler) without prepending the path. Those path entries start with the Z: drive, pointing to Z:\opt . The attached screenshots show what i entered in the registry under HKCU\Environment\PATH. Now, when i try to invoke the cl.exe compiler for example from a wine cmd like WINEPREFIX=/home/martin/wine-vc14-64 wine cmd i get following output: Z:\home\martin\Schreibtisch\Blender_DEV_gitlab\blender>cl.exe 'cl.exe' could not be recognized as internal or external command or as batch script. (Original german output:) 'cl.exe' konnte nicht als interner oder externer Befehl oder als Batch-Skript erkannt werden. But echo %PATH% shows: C:\windows\system32;C:\windows;C:\windows\system32\wbem;C:\ninja;Z:\opt\msvc\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x64;Z:\opt\winsdk\win10sdk\bin\10.0.17763.0\x64 so the path at this place seems to be correctly expanded. But the file cl.exe being there cannot be found. This breaks the crosscompile invocation scheme. (CMake doesnt find it, etc etc) I have also asked this question in IRC and i was recommended to file a bug report, since this works correctly under windows. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46901 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 CC| |dark.shadow4(a)web.de Status|UNCONFIRMED |NEW --- Comment #1 from Fabian Maurer <dark.shadow4(a)web.de> --- Confirming. Simple test case: create folder c:\winetest create batch file c:\winetest\winetest1.bat Add two environment variables: TESTVAR1 - winetest PATH - C:\%TESTVAR1% under wine: regedit - under HKCU/Environment under windows: add as global environment variables open cmd, type "winetest1" and press enter -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46901 --- Comment #2 from scorpion81 <scorpion8182(a)googlemail.com> --- Created attachment 63992 --> https://bugs.winehq.org/attachment.cgi?id=63992 workaround patch for PATH variable expansion in cmd itself Hmm what i found out so far by putting printfs into the wine sources is, that the persistent env vars in its registry are just sorted and expanded in alphabetical name order. That does not necessarily match with the variable expansion order, aka lexically larger names can occur as variables in values of lexically smaller names. E.g. INCLUDE = %VC%\include;%SDK_INCLUDES%. Not only the PATH variable is affected, but also such other variables too. I tried to workaround this with a call to handleExpansion() inside WCMD_run_program. But this a not so nice hack imho, since it doesnt cover direct invocation like wine <program.exe> or even calls via the wine binfmt handler (during compilation process intermediate exes can be created and will be called by cmake for example, would need to adapt this in order to use direct invocation like wine <my.exe> or activate the binfmt handler, so wine is called transparently. What is necessary here imho is either respecting a manually set environment variable evaluation order in the registry somehow or determine the correct evaluation order automatically (like cmd handleExpansion seems to do it) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46901 scorpion81 <scorpion8182(a)googlemail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |scorpion8182(a)googlemail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46901 --- Comment #3 from Fabian Maurer <dark.shadow4(a)web.de> --- I did some tests on windows, and it doesn't always expand the variables either. And it seems to expand in lexical order, too. For example TESTVAR1=%TESTVAR2% TESTVAR2=%TESTVAR3% TESTVAR3=test (all set in the registry obviously) gives TESTVAR1=%TESTVAR2% TESTVAR2=test TESTVAR3=test Will do more testing soon. Problem is in GetEnvironmentVariableW, AFAIK. Could you test if your setup with the nested environment variables works on windows? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46901 --- Comment #4 from scorpion81 <scorpion8182(a)googlemail.com> --- Created attachment 63995 --> https://bugs.winehq.org/attachment.cgi?id=63995 Short Windows 10 Nested Variable Expansion Test Hmmmmm.... seems it works only partially in windows too :( That's bad. Maybe i will have to shorten my paths and just work without so many env vars lol... I guess / am afraid since it doesnt work in Windows as well, it wont be fixed (and how at all ? lol) under wine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46901 --- Comment #5 from Fabian Maurer <dark.shadow4(a)web.de> --- Created attachment 63996 --> https://bugs.winehq.org/attachment.cgi?id=63996 Source for a test program Attaching a test program - note that on windows you need to restart for the environment variable changes to take effect. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46901 --- Comment #6 from Fabian Maurer <dark.shadow4(a)web.de> --- Sent in a patch that fixes the issue here: https://source.winehq.org/patches/data/161583 Let's see how that goes. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46901 --- Comment #7 from scorpion81 <scorpion8182(a)googlemail.com> --- (In reply to Fabian Maurer from comment #6)
Sent in a patch that fixes the issue here: https://source.winehq.org/patches/data/161583 Let's see how that goes.
That patch works fine here, it expands all nested variables properly. But my (maybe overly) complex cross compile setup still fails with recent master, because it downloads some source archives during build process (those are https connections, and the CMAKE file() invokes the downloads.) Those downloads fail and leave a file of 0kb, which did not happen with 4.0. But thats a story for another bug report maybe, i just wanted to mention it here. Was also trying to let the setup run with linux clang-cl and the msvc-clang-cl tool chain file, but due to the heterogenous structure of the libs build systems (some have cmake, some do configure make, and some have predefined Makefiles with hardcoded stuff that needs to be live-patched during build process in order to make it work) its not so easy as i assumed it was. Mentioning this just to give a context and for completeness. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46901 --- Comment #8 from Fabian Maurer <dark.shadow4(a)web.de> --- I understand. When you make a new bug report, make sure to link it here as well. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46901 Fabian Maurer <dark.shadow4(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #9 from Fabian Maurer <dark.shadow4(a)web.de> --- Marking as WONTFIX, according to https://www.winehq.org/pipermail/wine-devel/2019-June/147248.html Unless there''s a program that depends on this, it won't be fixed, since it's easier to just work around the issue. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=46901 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #10 from Austin English <austinenglish(a)gmail.com> --- Closing. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla