CODEWITHSUNDEEP
windowsgitbashshellpipe
Bartosz Gościński
Bartosz Gościński

Reputation: 1580

pipe is returning empty string in bash in git for windows

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:

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

Upvotes: 10

Views: 2824

Answers (2)

michael
michael

Reputation: 9809

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.

Upvotes: 2

user6307369
user6307369

Reputation: 

basedir=$(dirname "$(echo "$0" | sed -e 's,\\,/,g')")

This seems like an example of the XY problem. Let us break down this line:

echo "$0"

This is usually the path to the script, for example ./alfa.sh

sed -e 's,\\,/,g'

This replaces backslashes with forward slashes. This is where this line starts to fall apart:

  1. You dont need the -e, you can just do sed 's,\\,/,g'

  2. You probably dont need the g, usually just going to be one slash as shown above

  3. Changing the slashes doesnt really make sense. Bash, even on Windows, is going to be using forward slashes already

  4. If for some reason the slashes do need to be changed, Sed is not the right tool for this anyway, cygpath is:

    $ cygpath -m 'C:\Program Files\Mozilla Firefox\firefox.exe'
C:/Program Files/Mozilla Firefox/firefox.exe

dirname

Now you are calling dirname after sed/cygpath. It should be called before, that way sed/cygpath dont have to replace as much:

basedir=$(cygpath -m "$(dirname "$0")")

Finally, the sed command is bad for another reason; if you are going to be spitting out a path, it should be an absolute one, because why not?

basedir=$(cygpath -am "$(dirname "$0")")

Notice now that no pipe is even involved. I will also add that this problem was introduced recently to the NPM repo. You might comment to the devs there.

Upvotes: 0

Related Questions