On Tue, Jun 14, 2016 at 06:30:04PM +1000, Tony Cook wrote: > 1.85 win32 XS-APItest t/win32.t local failures > ===== > 4.36 > > 2016/06/01 Wednesday > 1.75 win32 XS-APItest t/win32.t local failures > 3.98 win32 XS-APItest t/win32.t local failures > ===== > 5.73 Actually I was planning on writing this one up - mostly with a copy and paste from the commit message: Encountered while testing locally on Windows 7 x64. cmd.exe stores the current directory for each drive as entries in the environment, like: C:\Users\tony>set "" | findstr "^=" =::=::\ =C:=C:\Users\tony =D:=D:\ASM1061 When a Win32 build of perl built with USE_IMP_SYS starts up it saves the current directories of each drive in a per-thread structure so that each pseudo-forked process can have it's own set of drive current directories. If you run an external command, some versions of cmd.exe will add an entry to the environment storing the result of that command, for example: C:\Users\tony>set "" | find "ExitCode" C:\Users\tony>git status fatal: Not a git repository (or any of the parent directories): .git C:\Users\tony>set "" | find "ExitCode" =ExitCode=00000080 which is similar to the current directory entries. The sloppy parsing by VDir::FromEnv[WA]() would treat that as a current directory entry for the E: drive, copying the "tCode=...." into the current directory. Normally these values include a leading drive letter and \, like "E:\", but this case leaves us without that. Later, when harness spawns the child process it builds a new environment block, including the drive current directories, which is done by VDir::BuildEnvironmentSpace(). This, rather than using the index of the drive to build the "=C:=..." entries above, uses the first letter of the stored entry, so the environment block would have something like: =t:=tCode=00000080 which the child perl would treat as the current directory for the T: drive. The fix was to make the parsing in VDir::FromEnv[WA] less sloppy, as in d2bccf1b4e37b11ff1a8260cedb2164e0f382dcb.Thread Previous | Thread Next