在 #65 和 #133 中，我们都涉及到了 Cygwin 和 MSYS2 的问题。
第一次错误的认识
在第一次尝试解决这个问题的时候，我花了一下午，最终确认是在 Cygwin 上的 /usr/bin/curl 的问题。即，我认为三种不同环境下编译的 curl.exe （Cygwin 下、MSYS2下、原生Windows下）的行为不一致，所以最终归咎于上游。
新的认识
然而今天经过再次研究，发现这一问题的根源，并不是上述编译 curl 的环境或者编译配置等问题。而是整个 Cygwin 环境的问题：Cygwin 无法识别 nul 文件。而 MSYS2 修正了这个问题。
所以判断 Cygwin 环境成为了我们的一个主要目标。
检测Cygwin的方案
上一次，我们是使用 cygcheck.exe 这一命令来检测的，这一命令在 Cygwin 和 MSYS2 中都存在。@Yangmoooo 指出用户很有可能把 Git Bash 的路径加入 Windows 原生环境变量中，导致上述检测方案失效。
接着寻求其它方案：Cygwin 环境并没有暴露出任何环境变量，唯一的 CYG_SYS_BASHRC 也没有被 export 出来。通过环境变量的检测手段失败了，接着我想要通过路径来检测，然而 Windows 上的 access() 以及原生的 GetFileAttribute() 都无法检测到 /usr 这种目录。遂这种方案也失效。
鸡蛋问题
我们可以通过调用 which, test 等命令检测，但是在原生 Windows 上这个命令不存在，因而需要 >nul 2>nul，此时在 Cygwin 环境中，又会生成 nul 文件（即使内容为空，也会产生）。我们发现，我们又回去了，陷入了鸡生蛋蛋生鸡的问题。
所以我提出这个方案：仍然基于第一次的修改，但现在额外让用户付出一个小的代价：让 Cygwin 用户主动暴露一个 export ON_CYGWIN=1 供我们检测，检测到后，再利用我们现有的实现去迂回地测速。即，修改这一条件：https://github.com/RubyMetric/chsrc/blob/main/src/framework/core.c#L498
#if XY_On_Windows
// if (0==system ("cygcheck --version >nul 2>nul"))
if (getenv ("ON_CYGWIN"))
{
on_cygwin = true;
os_devnull = "/tmp/chsrc-measure-downloaded";
}
#endif
在 #65 和 #133 中，我们都涉及到了
Cygwin和MSYS2的问题。第一次错误的认识
在第一次尝试解决这个问题的时候，我花了一下午，最终确认是在
Cygwin上的/usr/bin/curl的问题。即，我认为三种不同环境下编译的curl.exe（Cygwin下、MSYS2下、原生Windows下）的行为不一致，所以最终归咎于上游。新的认识
然而今天经过再次研究，发现这一问题的根源，并不是上述编译
curl的环境或者编译配置等问题。而是整个Cygwin环境的问题：Cygwin无法识别nul文件。而MSYS2修正了这个问题。所以判断
Cygwin环境成为了我们的一个主要目标。检测
Cygwin的方案上一次，我们是使用
cygcheck.exe这一命令来检测的，这一命令在Cygwin和MSYS2中都存在。@Yangmoooo 指出用户很有可能把 Git Bash 的路径加入 Windows 原生环境变量中，导致上述检测方案失效。接着寻求其它方案：
Cygwin环境并没有暴露出任何环境变量，唯一的CYG_SYS_BASHRC也没有被export出来。通过环境变量的检测手段失败了，接着我想要通过路径来检测，然而 Windows 上的access()以及原生的GetFileAttribute()都无法检测到/usr这种目录。遂这种方案也失效。鸡蛋问题
我们可以通过调用
which,test等命令检测，但是在原生 Windows 上这个命令不存在，因而需要>nul 2>nul，此时在 Cygwin 环境中，又会生成nul文件（即使内容为空，也会产生）。我们发现，我们又回去了，陷入了鸡生蛋蛋生鸡的问题。所以我提出这个方案：仍然基于第一次的修改，但现在额外让用户付出一个小的代价：让
Cygwin用户主动暴露一个export ON_CYGWIN=1供我们检测，检测到后，再利用我们现有的实现去迂回地测速。即，修改这一条件：https://github.com/RubyMetric/chsrc/blob/main/src/framework/core.c#L498