Tests involving [exec program >> file] fail on MSYS2/MinGW-w64

[msteveb]

Tests involving [exec program >> file] fail on MSYS2/MinGW-w64

[msteveb]

I don't have the environment to be able to reproduce this error, so hopefully you or someone else can resolve it.

[dbohdan]

Right. I made this as a bookmark for myself and in hope someone else might notice.

[dbohdan]

The problem doesn't manifest when the Jim Tcl binary built with MinGW-w64 (jimsh.exe) executes plain Windows console programs like cmd.exe:

C:\msys32\home\User\jimtcl>jimsh.exe -e "exec cmd.exe /c echo hi >> hi.txt"


C:\msys32\home\User\jimtcl>type hi.txt
hi

This suggests the bug may be the result of a normal Windows binary (jimsh.exe) interacting with ones built specifically for the MSYS2 environment (echo.exe), meaning the scope of the bug is narrower than it seemed from the start. One thing to check now is if it is possible to reproduce it with programs other than Jim Tcl starting MSYS2 binaries, i.e., if the bug is specific to Jim Tcl.

Edit: Tcl 8.6.4 and busybox-w32 redirect the output of MSYS2 executables normally, meaning the source code to mainline Tcl's [exec] is worth comparing to Jim's.

[msteveb]

The windows code in jim-exec.c is derived in large part from Tcl 8.6
One of the few differences I notice in the create flags that are passed to CreateProcess(). Perhaps Jim needs DETACHED_PROCESS.

[msteveb]

I also notice that Tcl doesn't use FILE_APPEND_DATA. Instead after opening, it seeks to the end of the file with:

SetFilePointer(handle, 0, NULL, FILE_END);

[dbohdan]

Great find! Replacing FILE_APPEND_DATA with a call to SetFilePointer fixes all the append-related tests. (DETACHED_PROCESS didn't.) Now only 12.1 remains. I would simply add a unix constraint to it.

PR: #60.