MSYS2 pipes have stopped working in Microsoft Windows cmd.exe shell

[dustwanderer]

Hi, I updated my MSYS2 installation two or three months ago, I think. Everything went fine.

About two weeks ago I updated my MSYS2 installation again. My Windows batch scripts use MSYS2 commands, and they stopped working.

If I open the Windows command prompt/shell cmd.exe and run individual commands like printf "a" everything looks fine.

If I try to run concatenated commands like printf "a" | grep "a" it fails about once every three times. The command never ends, I get a blinking cursor with no output and no prompt. CTRL-C, CTRL-Z, CTRL-Q, CTRL-E do not return the prompt.

If the command has more pipes printf "a" | grep "a" | grep "a", it fails much more frequently.

These concatenated commands work fine when I use the bash shell. It seems that they also work with PowerShell, although I have tested them fewer times.

I updated Windows 10 x64 , rebooted, and reinstalled MSYS2. The problem persists. I also installed MSYS2 in a virtual machine with Windows 7 x64. The problem remains.

If I replace my updated C:\msys64\ folder by a year-old C:\msys64\ the problem disappears. Of course, some packages can not be installed in this older MSYS2, and I can't update it.

Best regards

[dustwanderer]

Update: PowerShell also fails

[lazka]

I think I saw some similar reports on the cygwin mailing list so maybe there is a fix upstream

[Biswa96]

How to reproduce this issue?

[cbrt64]

They've already fixed this upstream with https://github.com/msys2/msys2-runtime/commit/b4fc81edcc25b5c313ab3805dc0bcd015c370e62 and others. I tested current msys2-runtime (3.2.0-3) built with and without the above commit applied, confirming that fixes this issue.

@dustwanderer, for now rolling back msys2-runtime to 3.1.7-8 will mitigate (pacman -U /var/cache/pacman/pkg/msys2-runtime*-3.1.7-8-x86_64.pkg.tar.zst, assuming it's still in your cache).

To reproduce: in msys2 console,

$ echo 'int main() {}' | gcc -x c -o /tmp/2471 -
$ cp /usr/bin/msys-2.0.dll /tmp

then in cmd prompt,

> set PATH=
> cd /d c:\msys64\tmp
> 2471 | 2471 | 2471

Locks up every time for me. (Win10 x86_64)

[cbrt64]

Thanks, @mingwandroid, for these helpful directions. Though we never had a chance to meet, this isn't the first time you've helped someone with some little thing, and I'm sure it won't be the last. RIP, fellow nerd.

[lazka]

Thanks, I've created a backport here: https://github.com/msys2/msys2-runtime/pull/39

[dustwanderer]

Thank you very much for your prompt help, everyone. Following cbrt64's instructions, I downgraded msys2-runtime to 3.1.7-4 and everything works again.

I will check the availability of msys2-runtime 3.2.0-4 or older from time to time.

Best regards

[lazka]

@dustwanderer can you try the latest update?

[jeremyd2019]

I think this new update (probably the symlink patch from -4) has broken the ability to work with substed drives

$ subst
T:\: -> C:\blah\blah\MINGW-packages

$ ls /t/
ls: cannot access '/t/': No such file or directory

This worked fine with 3.2.0-3

[lazka]

Confirmed. There was a followup commit, maybe we need that too: https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=13fd26ecf5ca8417146d57b45aed0133435c3497

[lazka]

ah, no, that backport included it.

[jeremyd2019]

I tried to send an email to cygwin mailing list, but it may have gone to the great mailing list black hole (I didn't subscribe first)

[lazka]

I can't reproduce with the latest cygwin snapshot (which should have the same patch): https://cygwin.com/snapshots/

[lazka]

I can send something to the mailing list if you want. (if you tell me what)

[jeremyd2019]

I basically just sent what I posted here. But if it doesn't happen with upstream cygwin, something else may be going on. I don't see why it wouldn't though

[jeremyd2019]

My message did in fact go through, I was just still looking at the April archive page 😊