为什么redirect在pipe路故障的地方工作？

从理论上讲，这两条命令应该是等价的：

1

type tmp.txt | test.exe

2

test.exe < tmp.txt

我有一个涉及＃1的过程，多年来，工作得很好; 在去年的某个时候，我们开始用更新版本的Visual Studio编译程序，现在由于input格式错误（见下文）而失败了。 但＃2成功（没有例外，我们看到预期的产出）。 为什么＃2会在＃1失败的地方成功？

我已经能够减lesstest.exe到下面的程序。 我们的input文件每行只有一个标签，并统一使用CR / LF行尾。 所以这个程序不应该写入stderr：

#include <iostream> #include <string> int __cdecl main(int argc,char** argv) { std::istream* pIs = &std::cin; std::string line; int lines = 0; while (!(pIs->eof())) { if (!std::getline(*pIs,line)) { break; } const char* pLine = line.c_str(); int tabs = 0; while (pLine) { pLine = strchr(pLine,'t'); if (pLine) { // move past the tab pLine++; tabs++; } } if (tabs > 1) { std::cerr << "We lost a linebreak after " << lines << " good lines.n"; lines = -1; } lines++; } return 0; }

当通过＃1运行时，我得到下面的输出，每次都有相同的数字（在每种情况下，这是因为getline已经返回了两个连续的行，没有间接的换行符）。 当通过＃2运行时，有（正确）没有输出：

惊喜！ shell提示命令行开关

findstr Windows命令的正则expression式

有没有办法从命令行处理locking的文件，并释放它？

Postgres“psql未被识别为内部或外部命令”

冒号批量variables名称

We lost a linebreak after 8977 good lines. We lost a linebreak after 1468 good lines. We lost a linebreak after 20985 good lines. We lost a linebreak after 6982 good lines. We lost a linebreak after 1150 good lines. We lost a linebreak after 276 good lines. We lost a linebreak after 12076 good lines. We lost a linebreak after 2072 good lines. We lost a linebreak after 4576 good lines. We lost a linebreak after 401 good lines. We lost a linebreak after 6428 good lines. We lost a linebreak after 7228 good lines. We lost a linebreak after 931 good lines. We lost a linebreak after 1240 good lines. We lost a linebreak after 2432 good lines. We lost a linebreak after 553 good lines. We lost a linebreak after 6550 good lines. We lost a linebreak after 1591 good lines. We lost a linebreak after 55 good lines. We lost a linebreak after 2428 good lines. We lost a linebreak after 1475 good lines. We lost a linebreak after 3866 good lines. We lost a linebreak after 3000 good lines.

如何使用命令行别名在Cmder中使用带有空格的path创build联结

为什么我的stderrredirect在命令完成后结束？ 我该如何解决？

schtasks系统失败

有没有办法告诉sed忽略符号链接？

linux批量重命名目录和strip＃字符从名字

这原来是一个已知的问题 ：

该错误实际上是在较低级别的_read函数中，stdio库函数（包括fread和fgets）用于从文件描述符读取。

在_read中的错误如下：如果…

你正在阅读一个文本模式管道，

你调用_read来读取N个字节，

_read成功读取N个字节

读取的最后一个字节是一个回车（CR）字符，

那么_read函数将成功完成读取，但将返回N-1而不是N.结果缓冲区末尾的CR或LF字符不计入返回值中。

在这个bug报告的特定问题中，fread调用_read来填充流缓冲区。 _read报告它填充了缓冲区的N-1个字节，并且最终的CR或LF字符丢失。

这个bug基本上是对时序敏感的，因为_read是否可以成功从管道中读取N个字节取决于有多少数据写入了管道。 更改缓冲区大小或更改缓冲区刷新时间可能会降低问题发生的可能性，但在100％的情况下不一定能解决问题。

有几种可能的解决方法：

使用二进制管道，并在阅读器侧手动执行文本模式CRLF => LF翻译。 这并不是特别困难（扫描CRLF对的缓冲区;用一个LF替换它们）。

使用_osfhnd（fh）调用ReadFile，完全绕过阅读器一侧的CRT I / O库（尽管这也需要手动文本模式转换，因为OS不会为你做文本模式转换）

我们已经修复了通用CRT下一次更新的这个错误。 请注意，通用CRT是一个操作系统组件，独立于Visual C ++库提供服务。 通用CRT的下一次更新可能与今年夏天的Windows 10周年更新大约在同一时间。