Okay, here is the problem with the patch, the env var is NOT corrupted, only, if the env var is a utf8 char, that can be represented in the current system high ascii CP. If the utf8 char can not be represented in the current system high ascii CP, it is converted to 0x3F. On pre-patch Perls, the previous case results in a different letter, but not "?" appearing in the child process. I can't explain the letter Z from WE A. I made 2 perl files a parent and a reader and ran it on Perl 5.12 and 5.17 with OP's latest patch (shays code not included). The parent has a option to switch between a western europe char, and a cyrillic char. My system is CP 1252 normally. Make sure your console is chcp 65001 and Lucinda font is set. The parent (env2) was run as console as "perl -C7 env2.pl 1> resp512.txt 2>&1". All the files attached are in UTF8 not high ascii. Must open in a editor and manual switch to UTF8. Notepad and Write dont do it right. Note, that with WE A, 5.17 correctly passed through the WE A, but CYR b turned to ? substitution in the child process. Is this the correct behavior or the behavior we want or should the WideCharToMultiBytes be done to UTF8 and not system default CP? Then the issue is, do we want to pass a non UTF-16 narrow-ish env array with UTF8 through the ANSI/narrow CreateProcess that Perl uses? I decided NOT to study how %ENV works just to post this. I saw some strange behavior with %ENV and I wasn't sure whats correct and whats wrong behavior so I dropped the %ENV issue. If someone knows how %ENV is "supposed" to behave on windows with perl, or writes a "known good" script (on Unix or Windows) that uses %ENV for me to compare my results to, I can investigate the %ENV behavior I saw. --- via perlbug: queue: perl5 status: open https://rt.perl.org:443/rt3/Ticket/Display.html?id=113536Thread Previous | Thread Next