Repository navigation
Conversation
Cygwin's speclib doesn't handle dashes or dots. However, we are about to rename the output file name from `cygwin1.dll` to `msys-2.0.dll`. Let's preemptively fix up all the import libraries that would link against `msys_2_0.dll` to correctly link against `msys-2.0.dll` instead.
Many of our build processes are made up of a mix of Cygwin tools (makepkg/bash for starters) and native Windows tools. When building things the paths of input and output files and directories are often communicated between them via process arguments or environment variables. The problem here is that those are in many cases not compatible. This introduces some "magic" where passing Unix paths to Win32 applications (via command-line arguments and/or environment variables) are auto-converted to their Win32 variants. Sometimes, this behavior is undesirable (e.g. when passing regular expressions via the form that starts and ends in slashes, which this new logic can mistake for Unix paths). For these instances, there are two ways to disable the automatic path conversion: - by setting `MSYS_NO_PATHCONV` to a non-empty string, - surgically, by setting the `MSYS2_ENV_CONV_EXCL` and `MSYS2_ARG_CONV_EXCL` environment variables. Find a more verbose description at https://www.msys2.org/docs/filesystem-paths/. Co-authored-by: Christoph Reiter <[email protected]> Co-authored-by: 마누엘 <[email protected]> Co-authored-by: Johannes Schindelin <[email protected]>
…t without ACLs. - Can read /etc/fstab with short mount point format.
The new `winsymlinks` mode `deepcopy` (which is made the default) lets calls to `symlink()` create (deep) copies of the source file/directory. This is necessary because unlike Cygwin, MSYS2 does not try to be its own little ecosystem that lives its life separate from regular Win32 programs: the latter have _no idea_ about Cygwin-emulated symbolic links (i.e. system files whose contents start with `!<symlink>\xff\xfe` and the remainder consists of the NUL-terminated, UTF-16LE-encoded symlink target). To support Cygwin-style symlinks, the new mode `sysfile` is introduced. Co-authored-by: Johannes Schindelin <[email protected]> Co-authored-by: Jeremy Drake <[email protected]>
With MSys1, it was necessary to set the TERM variable to "msys". To allow for a smooth transition from MSys1 to MSys2, let's simply handle TERM=msys as if the user had not specified TERM at all and wanted us to use our preferred TERM value.
Strace is a Windows program so MSYS2 will convert all arguments and environment vars and that makes debugging msys2 software with strace very tricky.
Commit message for this code was: * strace.cc (create_child): Set CYGWIN=noglob when starting new process so that Cygwin will leave already-parsed the command line alonw." I can see no reason for it and it badly breaks the ability to use strace.exe to investigate calling a Cygwin program from a Windows program, for example: strace mingw32-make.exe .. where mingw32-make.exe finds sh.exe and uses it as the shell. The reason it badly breaks this use-case is because dcrt0.cc depends on globbing to happen to parse commandlines from Windows programs; irrespective of whether they contain any glob patterns or not. See quoted () comment: "This must have been run from a Windows shell, so preserve quotes for globify to play with later."
The biggest problem with strace spitting out `create_child: ...` despite being asked to be real quiet is that its output can very well interfere with scripts' operations. For example, when running any of Git for Windows' shell scripts with `GIT_STRACE_COMMANDS=/path/to/logfile` (which is sadly an often needed debugging technique while trying to address the many MSYS2 issues Git for Windows faces), any time the output of any command is redirected into a variable, it will include that `create_child: ...` line, wreaking havoc with Git's expectations. So let's just really be quiet when we're asked to be quiet. Signed-off-by: Johannes Schindelin <[email protected]>
When converting `/c/` to `C:\`, the trailing slash is actually really necessary, as `C:` is not an absolute path. We must be very careful to do this only for root directories, though. If we kept the trailing slash also for, say, `/y/directory/`, we would run into the following issue: On FAT file systems, the normalized path is used to fake inode numbers. As a result, `Y:\directory\` and `Y:\directory` have different inode numbers!!! This would result in very non-obvious symptoms. Back when we were too careless about keeping the trailing slash, it was reported to the Git for Windows project that the `find` and `rm` commands can error out on FAT file systems with very confusing "No such file or directory" errors, for no good reason. During the original investigation, Vasil Minkov pointed out in git-for-windows/git#1497 (comment), that this bug had been fixed in Cygwin as early as 1997... and the bug was unfortunately reintroduced into early MSYS2 versions. Signed-off-by: Johannes Schindelin <[email protected]>
When calling `cygpath -u C:/msys64/` in an MSYS2 setup that was installed into `C:/msys64/`, the result should be `/`, not `//`. Let's ensure that we do not append another trailing slash if the converted path already ends in a slash. This fixes #112 Signed-off-by: Johannes Schindelin <[email protected]>
Otherwise if globbing is allowed and we get called from a Windows program, build_argv thinks we've been called from a Cygwin program.
…spec Reverts 25ba8f3. I can't figure out what the intention was. I'm sure I'll find out soon enough when everything breaks. This change means that input of: '"C:/test.exe SOME_VAR=\"literal quotes\""' becomes: 'C:/test.exe SOME_VAR="literal quotes"' instead of: 'C:/test.exe SOME_VAR=\literal quotes\' .. which is at least consistent with the result for: '"no_drive_or_colon SOME_VAR=\"literal quotes\""' The old result of course resulted in the quoted string being split into two arguments at the space which is clearly not intended. I *guess* backslashes in dos paths may have been the issue here? If so I don't care since we should not use them, ever, esp. not at the expense of sensible forward-slash-containing input.
Works very much like MSYS2_ARG_CONV_EXCL. In fact it uses the same function, arg_heuristic_with_exclusions (). Also refactors parsing the env. variables to use new function, string_split_delimited (). The env. that is searched through is the merged (POSIX + Windows) one. It remains to be seen if this should be made an option or not. This feature was prompted because the R language (Windows exe) calls bash to run configure.win, which then calls back into R to read its config variables (LOCAL_SOFT) and when this happens, msys2-runtime converts R_ARCH from "/x64" to an absolute Windows path and appends it to another absolute path, R_HOME, forming an invalid path.
It is simply the negation of `disable_pcon`, i.e. `MSYS=enable_pcon` is equivalent to `MSYS=nodisable_pcon` (the former is slightly more intuitive than the latter) and likewise `MSYS=noenable_pcon` is equivalent to `MSYS=disable_pcon` (here, the latter is definitely more intuitive than the former). This is needed because we just demoted the pseudo console feature to be opt-in instead of opt-out, and it would be awkward to recommend to users to use "nodisable_pcon"... "nodisable" is not even a verb. Signed-off-by: Johannes Schindelin <[email protected]>
We mount /usr/bin to /bin, but in a chroot this is broken and we have no /bin, so try to use the real path. chroot is used by pacman to run install scripts when called with --root and this broke programs in install scripts calling popen() (install-info from texinfo for example) There are more paths hardcoded to /bin in cygwin which might also be broken in this scenario, so this maybe should be extended to all of them.
It does not work at all. For example, `rpm -E %fedora` says that there should be version 33 of rpmsphere at https://github.com/rpmsphere/noarch/tree/master/r, but there is only version 32. Another thing that is broken: Cygwin now assumes that a recent mingw-w64-headers version is available, but Fedora apparently only offers v7.0.0, which is definitely too old to accommodate for the expectation of cygwin/cygwin@c1f7c4d1b6d7. Signed-off-by: Johannes Schindelin <[email protected]>
Collaborator
Author
Totally! |
Build with --disable-dependency-tracking because we only build once and this saves 3-4 minutes in CI.
This will help us by automating an otherwise tedious task. Signed-off-by: Johannes Schindelin <[email protected]>
In the Cygwin project, it was decided that the command-line of Cygwin processes, as shown in the output of `wmic process list`, would suffer from being truncated to 32k (and is transmitted to the child process via a different mechanism, anyway), and therefore only the absolute path of the executable is shown by default. Users who would like to see the full command-line (even if it is truncated) are expected to set `CYGWIN=wincmdln` (or, in MSYS2's case, `MSYS=wincmdln`). Seeing as MSYS2 tries to integrate much better with the surrounding Win32 ecosystem than Cygwin, it makes sense to turn this on by default. Users who wish to suppress it can still set `MSYS=nowincmdln`. Signed-off-by: Johannes Schindelin <[email protected]>
In particular, we are interested in the address of the CtrlRoutine and the ExitProcess functions. Since kernel32.dll is loaded first thing, the addresses will be the same for all processes (matching the CPU architecture, of course). This will help us with emulating SIGINT properly (by not sending signals to *all* processes attached to the same Console, as GenerateConsoleCtrlEvent() would do). Co-authored-by: Naveen M K <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
This patch is heavily inspired by the Git for Windows' strategy in handling Ctrl+C. When a process is terminated via TerminateProcess(), it has no chance to do anything in the way of cleaning up. This is particularly noticeable when a lengthy Git for Windows process tries to update Git's index file and leaves behind an index.lock file. Git's idea is to remove the stale index.lock file in that case, using the signal and atexit handlers available in Linux. But those signal handlers never run. Note: this is not an issue for MSYS2 processes because MSYS2 emulates Unix' signal system accurately, both for the process sending the kill signal and the process receiving it. Win32 processes do not have such a signal handler, though, instead MSYS2 shuts them down via `TerminateProcess()`. For a while, Git for Windows tried to use a gentler method, described in the Dr Dobb's article "A Safer Alternative to TerminateProcess()" by Andrew Tucker (July 1, 1999), http://www.drdobbs.com/a-safer-alternative-to-terminateprocess/184416547 Essentially, we injected a new thread into the running process that does nothing else than running the ExitProcess() function. However, this was still not in line with the way CMD handles Ctrl+C: it gives processes a chance to do something upon Ctrl+C by calling SetConsoleCtrlHandler(), and ExitProcess() simply never calls that handler. So for a while we tried to handle SIGINT/SIGTERM by attaching to the console of the command to interrupt, and generating the very same event as CMD does via GenerateConsoleCtrlEvent(). This method *still* was not correct, though, as it would interrupt *every* process attached to that Console, not just the process (and its children) that we wanted to signal. A symptom was that hitting Ctrl+C while `git log` was shown in the pager would interrupt *the pager*. The method we settled on is to emulate what GenerateConsoleCtrlEvent() does, but on a process by process basis: inject a remote thread and call the (private) function kernel32!CtrlRoutine. To obtain said function's address, we use the dbghelp API to generate a stack trace from a handler configured via SetConsoleCtrlHandler() and triggered via GenerateConsoleCtrlEvent(). To avoid killing each and all processes attached to the same Console as the MSYS2 runtime, we modify the cygwin-console-helper to optionally print the address of kernel32!CtrlRoutine to stdout, and then spawn it with a new Console. Note that this also opens the door to handling 32-bit process from a 64-bit MSYS2 runtime and vice versa, by letting the MSYS2 runtime look for the cygwin-console-helper.exe of the "other architecture" in a specific place (we choose /usr/libexec/, as it seems to be the convention for helper .exe files that are not intended for public consumption). The 32-bit helper implicitly links to libgcc_s_dw2.dll and libwinpthread-1.dll, so to avoid cluttering /usr/libexec/, we look for the helped of the "other" architecture in the corresponding mingw32/ or mingw64/ subdirectory. Among other bugs, this strategy to handle Ctrl+C fixes the MSYS2 side of the bug where interrupting `git clone https://...` would send the spawned-off `git remote-https` process into the background instead of interrupting it, i.e. the clone would continue and its progress would be reported mercilessly to the console window without the user being able to do anything about it (short of firing up the task manager and killing the appropriate task manually). Note that this special-handling is only necessary when *MSYS2* handles the Ctrl+C event, e.g. when interrupting a process started from within MinTTY or any other non-cmd-based terminal emulator. If the process was started from within `cmd.exe`'s terminal window, child processes are already killed appropriately upon Ctrl+C, by `cmd.exe` itself. Also, we can't trust the processes to end it's subprocesses upon receiving Ctrl+C. For example, `pip.exe` from `python-pip` doesn't kill the python it lauches (it tries to but fails), and I noticed that in cmd it kills python also correctly, which mean we should kill all the process using `exit_process_tree`. Co-authored-by: Naveen M K <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
This change is the equivalent to the change to the Ctrl+C handling we just made. Co-authored-by: Naveen M K <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
This code has been causing issues with SUBST and mapped network drives, so add an option (defaulted to on) which can be used to disable it where needed. MSYS=nonativeinnerlinks
The MSYS2 packages lack the infrastructure to build those. Signed-off-by: Johannes Schindelin <[email protected]>
It frequently leads to problems when trying, say, to call from MSYS2's
Bash into Cygwin's or Git for Windows', merely because sharing that data
is pretty finicky.
For example, using the MSYS2' Bash using the MSYS2 runtime version that
is current at time of writing, trying to call Cygwin's programs fails
in manners like this:
$ /c/cygwin64/bin/uname -r
0 [main] uname (9540) child_copy: cygheap read copy failed, 0x800000000..0x800010BE0, done 0, windows pid 9540, Win32 error 6
680 [main] uname 880 C:\cygwin64\bin\uname.exe: *** fatal error - couldn't create signal pipe, Win32 error 5
with the rather misleading exit code 127 (a code which is reserved to
indicate that a command was not found).
Let's just treat the MSYS2 runtime and the Cygwin runtime as completely
incompatible with one another, by virtue of using a different
magic constant than merely `CHILD_INFO_MAGIC`.
By using the msys2-runtime commit to modify that magic constant, we can
even spawn programs using a different MSYS2 runtime (such as Git for
Windows') because the commit serves as the tell-tale whether two MSYS2
runtime versions are compatible with each other. To support building in
the MSYS2-packages repository (where we do not check out the
`msys2-runtime` but instead check out Cygwin and apply patches on top),
let's accept a hard-coded commit hash as `./configure` option.
One consequence is that spawned MSYS processes using a different MSYS2
runtime will not be visible as such to the parent process, i.e. they
cannot share any resources such as pseudo terminals. But that's okay,
they are simply treated as if they were regular Win32 programs.
Note: We have to use a very rare form of encoding the brackets in the
`expr` calls: quadrigraphs (for a thorough explanation, see
https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/html_node/Quadrigraphs.html#Quadrigraphs).
This is necessary because it is apparently impossible to encode brackets
in `configure.ac` files otherwise.
Signed-off-by: Johannes Schindelin <[email protected]>
Having just Cygwin's version in the output of `uname` is not helpful, as both MSYS2 as well as Git for Windows release intermediate versions of the MSYS2 runtime much more often than Cygwin runtime versions are released. Signed-off-by: Johannes Schindelin <[email protected]>
Reportedly a very recent internal build of Windows 11 once again changed the current working directory logic a bit, and Cygwin's "magic" (or: "technologically sufficiently advanced") code needs to be adjusted accordingly. In particular, the following assembly code can be seen: ntdll!RtlpReferenceCurrentDirectory 598 00000001`800c6925 488d0db4cd0f00 lea rcx,[ntdll!FastPebLock (00000001`801c36e0)] 583 00000001`800c692c 4c897810 mov qword ptr [rax+10h],r15 588 00000001`800c6930 0f1140c8 movups xmmword ptr [rax-38h],xmm0 598 00000001`800c6934 e82774f4ff call ntdll!RtlEnterCriticalSection The change necessarily looks a bit different than 4840a56 (Cygwin: Adjust CWD magic to accommodate for the latest Windows previews, 2023-05-22): The needle `\x48\x8d\x0d` is already present, as the first version of the hack after Windows 8.1 was released. In that code, though, the `call` to `RtlEnterCriticalSection` followed the `lea` instruction immediately, but now there are two more instructions separating them. Note: In the long run, we may very well want to follow the insightful suggestion by a helpful Windows kernel engineer who pointed out that it may be less fragile to implement kind of a disassembler that has a better chance to adapt to the ever-changing code of `ntdll!RtlpReferenceCurrentDirectory` by skipping uninteresting instructions such as `mov %rsp,%rax`, `mov %rbx,0x20(%rax)`, `push %rsi` `sub $0x70,%rsp`, etc, and focuses on finding the `lea`, `call ntdll!RtlEnterCriticalSection` and `mov ..., rbx` instructions, much like it was prototyped out for ARM64 at https://gist.github.com/jeremyd2019/aa167df0a0ae422fa6ebaea5b60c80c9 Signed-off-by: Johannes Schindelin <[email protected]>
During signal delivery, Cygwin saves the CPU's extended register state (floating-point, SSE, AVX, etc.) to a stack buffer using the xsave64 instruction, which requires its destination to be 64-byte aligned. Before executing xsave64, the code queries the CPU (via cpuid) for the required buffer size, then subtracts that size (plus a fixed overhead) from the stack pointer. The stack alignment arithmetic assumes that cpuid returns a size that is a multiple of 64. Until recently, this held true for all x86 CPUs. On recent AMD and Intel CPUs, however, the PKU feature (Protection Keys for Userspace, a memory-protection mechanism) adds an XSAVE component of only 8 bytes, which makes the total size no longer a multiple of 64. The subtraction then places the xsave64 buffer at a misaligned address, causing a segfault. This was first observed when running Cygwin/MSYS2 under Wine on Linux, where the host kernel exposes the PKU feature directly. The same problem could surface on future Windows versions that expose PKU or other small XSAVE components. The fix rounds up the cpuid-reported size to the next 64-byte multiple before using it in the stack allocation. The existing code already guarantees correct alignment for any buffer size that is a multiple of 64, so this rounding is sufficient. Fixes: c607889 ("Cygwin: sigfe: Fix a bug that signal handler destroys fpu states") Signed-off-by: Pip Cet <[email protected]>
dscho
force-pushed
the
tentative/msys2-3.6.11
branch
from
October 2, 2026 08:48
68eefc7 to
4ca0a54
Compare
Collaborator
Author
Done! The force-pushed commit is tree-same. Range-diff
|
Member
|
lgtm |
Collaborator
Author
|
It's concerning that |
Currently, when cygwin app is launched, the console input mode is
set to tty::cygwin, even if the stdin is not a console. However,
it is not necessary because the cygwin app does not use stdin.
This also applies to stdout and stderr.
With this patch, the console mode is set only when std{in,out,err}
is a console for the cygwin app for better coexistence with non-
cygwin apps.
This is a prerequisite for the experimental backport of Takashi Yano's
v15 console-mode patch to msys2-3.6.10. The release branch's later,
already-applied suspension-before-mode ordering is preserved.
(cherry picked from commit bbd3710)
Assisted-by: GPT-6
Signed-off-by: Takashi Yano <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
dscho
force-pushed
the
tentative/msys2-3.6.11
branch
from
October 2, 2026 13:44
4ca0a54 to
c0b496f
Compare
Collaborator
Author
And sure enough, I resolved a merge conflict incorrectly, which was the cause for that regression, and it totally concerns this here PR. The force-push fixes this. |
Member
|
I just hit the same hang in https://github.com/msys2/msys2-tests/actions/runs/36988280346/job/110778261474 and https://github.com/msys2/msys2-tests/actions/runs/37110665545/job/111167793137 - so seems to exist without this. |
Member
|
And it's quite consistent in CI, I wonder what changed. |
dscho
added a commit
to dscho/msys2-runtime
that referenced
this pull request
Oct 3, 2026
The compiler ABI check in msys2/msys2-runtime#375 hung for nearly six hours, but the same artifact passed it in 24 seconds in the first diagnostic run. A later, unrelated symlink failure prevented Copilot from analyzing the original timeout. Isolate and repeat the suspect CMake check, retaining intermediate evidence whether the hang recurs or the investigation stops early. Assisted-by: GPT-6.1 Sol Signed-off-by: Johannes Schindelin <[email protected]>
Collaborator
Author
Hmm. Even funnier: this PR hangs, but Git for Windows' PR does not hang... I wonder, therefore, whether the difference is in one of the not-yet-upstreamed patches in Git for Windows. |
dscho
added a commit
to dscho/msys2-runtime
that referenced
this pull request
Oct 3, 2026
A focused run of msys2/msys2-runtime#375 reproduced the CMake ABI wait, but the job expired before uploading Copilot's diagnosis. Most of its job log was machine-generated JSONL, obscuring the findings. Stream readable checkpoints as they are written and retain enough time for artifact upload; start the next session from the recovered evidence rather than repeating it. Assisted-by: GPT-6.1 Sol Signed-off-by: Johannes Schindelin <[email protected]>
dscho
added a commit
to dscho/msys2-runtime
that referenced
this pull request
Oct 3, 2026
Use the requested Git for Windows candidate for a controlled test of the intermittent GCC/CMake ABI CI hang reported in msys2/msys2-runtime#375. The original rationale about potential collisions involving injected DLLs and runtime shared mappings is only a hypothesis for this hang, not a demonstrated cause. Cherry-picked-from: 8917888 (Change the default base address for x86_64, 2022-03-10) Assisted-by: GPT-6.1 Sol Signed-off-by: Johannes Schindelin <[email protected]>
Member
|
Just as a warning: I tried to reduce it to what package update triggered it, and I just ran 18 CI jobs, and only 4 hung. edit: it's also reproducible with latest installer + 3.6.10-1, so I think it's not a regression in the runtime. Maybe something triggered an existing bug though. |
dscho
added a commit
to dscho/msys2-runtime
that referenced
this pull request
Oct 4, 2026
The original failing MSYS-gcc run and passing Git for Windows run used CMake 4.4.3. The latest paired comparison used 4.4.4 in both arms, so it did not match the original software stack. Remove that known version confound before collecting live stack and module evidence for msys2/msys2-runtime#375. This does not establish that 4.4.4 caused the timeout or that restoring 4.4.3 fixes it. Assisted-by: GPT-6.1 Sol Signed-off-by: Johannes Schindelin <[email protected]>
dscho
added a commit
to dscho/msys2-runtime
that referenced
this pull request
Oct 4, 2026
The full-target control in msys2/msys2-runtime#375 timed out without stack or module captures. Earlier libuv/signal-pipe clues came from a different, narrowed reproducer and do not establish the same cause. Obtain the missing live-process evidence before claiming a root cause or attributing a fix. Capture must precede the CI deadline without killing the original process, so the stalled state remains available for diagnosis. Assisted-by: GPT-6.1 Sol Signed-off-by: Johannes Schindelin <[email protected]>
dscho
added a commit
to dscho/msys2-runtime
that referenced
this pull request
Oct 5, 2026
The focused run passed all 32 full targets, but its checkout and process I/O differed from the original action in msys2/msys2-runtime#375. That result does not rule out the intermittent failure. Keep this temporary CI investigation faithful to the original execution context so it can provide comparable evidence. This is not a runtime fix or a claim about the root cause. Assisted-by: GPT-6.1 Sol Signed-off-by: Johannes Schindelin <[email protected]>
dscho
added a commit
to dscho/msys2-runtime
that referenced
this pull request
Oct 6, 2026
The proposed correction for the intermittent GCC/CMake hang needs evidence from a compiled, installed and loaded runtime, not just counter analysis. See msys2/msys2-runtime#375 for context. Keep this temporary CI branch focused on GCC verification, with the original DLL as an isolated control at the unchanged image base. The unrelated matrix remains out of scope. Expected control probe failures establish that the checks exercise the regression; they must not be reported as candidate failures. Assisted-by: GPT-6.1 Signed-off-by: Johannes Schindelin <[email protected]>
Collaborator
Author
Yep, that bug (or better: flake) is real, and it seems as if a variation of https://inbox.sourceware.org/cygwin-patches/[email protected]/fixes it. I'm working on a fix with a proper test case. |
Collaborator
Author
Submitted as https://inbox.sourceware.org/cygwin-patches/[email protected]/ |
With console stdin but captured stdout and stderr, a runtime child can replace the shared saved output mode with zero. A later invocation restores that value, rendering CR/LF as glyphs instead of line breaks. Redirected stdin with console output exposes the corresponding input-mode omission. Console handlers restore both modes on close, even with redirected stdio. Keep their backups valid regardless of whether opening the handler needs to switch either mode. Addresses: #379 Fixes: bbd3710 ("Cygwin: console: Set console mode only if std{in,out,err} is console") Cherry-picked-from: acfe4b4 (Cygwin: console: Preserve saved modes with redirected stdio, 2026-10-08) Assisted-by: GPT-6.1 Signed-off-by: Johannes Schindelin <[email protected]>
When stdout and stderr are redirected but stdin remains attached to the console, starting a Cygwin child via a native launcher must not clear ENABLE_PROCESSED_OUTPUT. Protect the behavior restored by 717d7aac57 (Cygwin: console: Preserve saved modes with redirected stdio) against future regressions. Addresses: #379 Cherry-picked-from: e0c179b (Cygwin: testsuite: cover console mode preservation with redirected stdio, 2026-10-08) Assisted-by: GPT-6.1 Signed-off-by: Johannes Schindelin <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Range-diff relative to msys2-3.6.10
1: c7fae92 = 1: 40325b0 Fix msys library name in import libraries
2: 83eb499 = 2: 6270157 Rename dll from cygwin to msys
3: 612c696 = 3: a2f386e Convert Unix paths in args/env to Windows form for native Win32 apps
4: 874d256 = 4: 20f6197 Add functionality for changing OS name via MSYSTEM environment variables.
5: 67e0663 = 5: b5bc62a - Move root to /usr. - Change sorting mount points. - By default mount without ACLs. - Can read /etc/fstab with short mount point format.
6: dc304d9 = 6: 373a34a Instead of creating Cygwin symlinks, use deep copy by default
7: 62649f0 = 7: 9584e94 Automatically rewrite TERM=msys to TERM=cygwin
8: 3b75044 = 8: 9b5d551 Do not convert environment for strace
9: 88822d8 = 9: 6c7d224 strace.cc: Don't set MSYS=noglob
10: 41812f5 = 10: 4bfb55b Add debugging for strace make_command_line
11: 8c4ab21 = 11: 004c621 strace --quiet: be really quiet
12: f2a033d = 12: 33516d8 path_conv: special-case root directory to have trailing slash
13: f5ab94d = 13: ce5a5c5 When converting to a Unix path, avoid double trailing slashes
14: 6c551e9 = 14: 3021a21 dcrt0.cc: Untangle allow_glob from winshell
15: 145bb5c = 15: 248ad25 dcrt0.cc (globify): Don't quote literal strings differently when dos_spec
16: 8949d0d = 16: 1edbad5 Add debugging for build_argv
17: c78d8a5 = 17: 1bee732 environ.cc: New facility/environment variable MSYS2_ENV_CONV_EXCL
18: 6673896 = 18: 8496a08 Introduce the
enable_pconvalue forMSYS19: 8df76a0 = 19: cf8cb2a popen: call /usr/bin/sh instead of /bin/sh
20: bb5abd5 = 20: ececb65 Disable the 'cygwin' GitHub workflow
21: 6e6dac8 = 21: 0661fd8 CI: add a GHA for doing a basic build test
22: 3280370 = 22: 2eb1cf7 Set up a GitHub Action to keep in sync with Cygwin
23: cf378f2 = 23: 65d15e6 Expose full command-lines to other Win32 processes by default
24: 75ea5cb = 24: 318b783 Add a helper to obtain a function's address in kernel32.dll
25: c93ce39 = 25: fd45df4 Emulate GenerateConsoleCtrlEvent() upon Ctrl+C
26: 5df8ad8 = 26: 2110758 kill: kill Win32 processes more gently
27: 369346a = 27: 1dcffba Cygwin: make option for native inner link handling.
28: aa1cb2c = 28: 69491ba docs: skip building texinfo and PDF files
29: 0f9b6de = 29: c6bef9e install-libs: depend on the "toollibs"
30: 3244d7c = 30: d49d4ef POSIX-ify the SHELL variable
31: d71bdf6 = 31: ae764fd Handle ORIGINAL_PATH just like PATH
32: fc06dfd = 32: 9463d96 uname: allow setting the system name to CYGWIN
33: 2bda763 = 33: 61b9ef5 Pass environment variables with empty values
34: 6588ea9 = 34: 2bb2d55 Optionally disallow empty environment values again
35: 989297d = 35: 0c0a4ae build_env(): respect the
MSYSenvironment variable36: f53fdff = 36: 1f55a7f Revert "Cygwin: Enable dynamicbase on the Cygwin DLL by default"
37: a921c18 = 37: 051e719 Avoid sharing cygheaps across Cygwin versions
38: 98f9ae0 = 38: c4a2f27 uname: report msys2-runtime commit hash, too
39: 3bf64eb = 39: 4b29a17 Cygwin: Adjust CWD magic to accommodate for the latest Windows previews
40: 2558ff9 = 40: a49b2df Cygwin: Fix segfault when XSAVE area sizes are unaligned
41: 9a6cbe5 (upstream: b73bb4b) < -: --------- cygcheck: remove an unused variable causing a build error with GCC 16
42: 2105f6c = 41: dcb1524 fixup! CI: add a GHA for doing a basic build test
43: 154c310 (upstream: 110e655) < -: --------- dumper: allow compiling with binutils 2.47
44: 8fbd980 (upstream: 273e661) < -: --------- Cygwin: open: Unlock fdtab before open_with_arch()
45: da84778 (upstream: 7e802b8) < -: --------- Cygwin: console: Fix regression in console input
46: c892dfe ! 42: 68eefc7 Cygwin: console: Set console mode only if std{in,out,err} is console
47: 92c1e00 (upstream: f05c9b7) < -: --------- Cygwin: console: Fix undesired mode change at exit of non-cygwin apps
48: c770e1b (upstream: ad6db4d) < -: --------- Cygwin: console: Abort setting disable_master_thread when no con.owner
49: 3ea87a5 (upstream: 41d997c) < -: --------- Cygwin: console: Avoid deadlock with app execution aliases