[Bug 46901] Path environment variable with nested variables is not expanded properly

wine-bugs at winehq.org wine-bugs at winehq.org
Mon Mar 25 13:57:39 CDT 2019


https://bugs.winehq.org/show_bug.cgi?id=46901

--- Comment #2 from scorpion81 <scorpion8182 at 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.



More information about the wine-bugs mailing list