管道在git的bash中以bash返回空字符串 [英] pipe is returning empty string in bash in git for windows

问题描述

一些评论指的是该问题背后的完整故事"，但我决定将其缩短，因为它变得太长且难以理解.我以尽可能简洁的失败例子向您介绍.对于那些有兴趣了解该问题的完整上下文的人员:可以在该问题的先前修订版本中找到.

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.

此: basedir = $(dirname"$(echo" $ 0"| sed -e's，\\，/，g')")是其中的第一行(不包括hashbang)在安装CLI附带的任何软件包后，由npm 生成脚本.由于某些原因， basedir 的解析错误，这就是节点无法找到模块而导致崩溃的原因.我设法将问题缩小到最新Git for Windows的git-bash子外壳中的管道.执行中:

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")"

打印:

1:a
2:
3:a

我找不到其他遇到此问题的人，所以我认为我的环境(Windows 10 Pro，适用于Windows 2.8.4的Git)出了点问题，我个人不知道它可能来自何处.我的发现:

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:

• 将Windows的Git降级到2.6.4可以解决此问题.仍然我不喜欢停留在旧版本上；/
• 在干净的Windows 10 VM上正常运行
• 管道输出似乎完全为空，因为按照以下代码段运行不会返回任何结果.
• 在干净安装mingw + msys时不会发生

摘要:

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

感谢AGC在此方面提供了宝贵的帮助.

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

我的 PATH 变量如下所示:

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

也

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

推荐答案

总结注释，简短的(tl; dr)版本:降级，升级和/或重新安装Git for Windows附带的MSYS和MinGW

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 补充了 Git for Windows 可以从MSYS的原始维护者那里进行修改.出现了针对MSYS的错误报告，原因似乎是同一问题(使用"mingw版本:与git版本2.8.3.windows.1捆绑在一起的64位)，但被标记为对我有用"(即无法复制").但有评论认为问题可能出在重新包装中:

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:

请注意，与Windows的git捆绑在一起的MSYS可能会从我们的官方发行版中进行修改(并且64位MinGW当然不是我们的；因此，我们不正式支持这两种方式." https://sourceforge.net/p/mingw/bugs/2303/

长话短说，看起来像个虫子.

Long story short, looks like a bug.

这篇关于管道在git的bash中以bash返回空字符串的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！