pipe is returning empty string in bash in git for windows

Question

Edit: Issue has been resolved after update to Git for Windows >= 2.9.0.windows1

---

Disclaimer

Some comments are referring to full "story" behind this issue but I decided to shorten it because it was getting too long and hard to follow. I present you as succinct failing example as possible. For those who are interested in knowing full context of the problem: it is available in previous revision of the question.

---

This: basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')") is the first (excluding hashbang) line in scripts generated by npm after installing any package which comes with CLI. For some reason basedir is incorrectly resolved and that's why node can't find module and crashes. I managed to narrow down problem to the pipe in subshell on latest Git for Windows' git-bash. Executing:

echo -n "1:"
echo "a" | cat
echo -n "2:"
echo "$(echo "a" | cat)"
echo -n "3:"
echo "$(echo "a")"

prints:

1:a
2:
3:a

I can't find other people with this issue so I think that it's something wrong with my env (Windows 10 Pro, Git for Windows 2.8.4) and personally I'm out of ideas where it might come from. My findings:

• downgrading Git for Windows to 2.6.4 fixes the problem. Still I don't like being stuck on old version ;/
• it works fine on clean Windows 10 VM
• pipe output seems to be completely empty because running following snippet doesn't return any result.
• On clean installation of mingw + msys problem doesn't occur

snippet:

echo $(echo foobar | cat > bazzzzzzzzzz ; ) ; cat bazzzzzzzzzz
find /c -name bazzzzzzz* 2> /dev/null # /c, /d and /x are my Windows partitions
find /d -name bazzzzzzz* 2> /dev/null # I did test if it actually works for existing file and it does
find /x -name bazzzzzzz* 2> /dev/null

Thanks to agc for invaluable help on figuring this out to this point.

---

My PATH variable looks like this:

PATH=/c/Users/ja/bin:/mingw64/bin:/usr/local/bin:/usr/bin:/bin:/mingw64/bin:/usr/bin:/c/Users/ja/bin:/c/Windows:/c/Windows/System32:/c/Windows/System32/Wbem:/c/Windows/System32/WindowsPowerShell/v1.0:/c/Program Files/nodejs:/c/ProgramData/Oracle/Java/javapath:/c/program files/graphicsmagick-1.3.23-q16:/c/ProgramData/chocolatey/lib/getopt/binaries:/c/Program Files (x86)/Windows Kits/8.1/Windows Performance Toolkit:/c/Program Files/nodejs:/c/Program Files (x86)/Microsoft VS Code/bin:/c/Users/ja/AppData/Roaming/npm:/c/Program Files (x86)/MacType:/usr/bin/vendor_perl:/usr/bin/core_perl

also

$ which sed
/usr/bin/sed
$ which echo
/usr/bin/echo
$ which cat
/usr/bin/cat
$ echo $SHELL
/usr/bin/bash

Answer 1

Summarizing the comments, the short (tl;dr) version: either downgrade, upgrade, and/or re-install MSYS and MinGW that come with Git for Windows.

MSYS supplements MinGW, and the version provided by Git for Windows may be modified from the original maintainers of MSYS. There was a bug reported against MSYS for what appears to be this same issue (using "mingw version: 64 bit bundled with git version 2.8.3.windows.1"), but was marked as "works for me" (i.e., "can't reproduce"). But there was a comment that the problem could be in the repackaging:

"Please be advised that MSYS, as bundled with git for windows, may be modified from our official distribution, (and 64-bit MinGW certainly isn't ours); thus we don't formally support either of these." https://sourceforge.net/p/mingw/bugs/2303/

Long story short, looks like a bug.