Windows 为什么XCOPY/W和REPLACE/W使用所有重定向的文本数据作为一个字符的提示？

当文本文件

test.txt

包含此1时：

以下代码返回删除第一个字符的文本文件内容：

< "test.txt" (
    > nul pause
    findstr "^"
)

因为

pause

命令只需要一个字符

但是，当用以下任一命令替换

pause

命令时，输出为空，尽管与

pause

类似，它们只提示（

/W

）单个字符：

• 2>nul xcopy/W

• 更换/W/U

为什么会这样，这里发生了什么？

xcopy/W

和

replace/W

是否使用所有重定向/管道传输的文本数据，甚至多行，尽管它们只显示接收到的第一个字符？他们在摆弄文件指针吗？
有没有办法防止这些命令吸收一个以上的字符

---

---

1…最后一行以换行符终止，以便

findstr

不无限期挂起–请参阅此线程：，部分»如果重定向的输入未以

«结束，则findstr在XP和Windows 7上挂起。

重定向与管道之间的行为实际上有所不同

重定向 XCOPY和REPLACE似乎只是将stdin文件指针移动到文件末尾（EOF）

如果使用

FIND/V”“

而不是

FINDSTR“^”

，则会将整个文件作为输出，因为FIND会在启动时将文件指针重置为文件的开头。因此，在XCOPY运行后，stdin流仍然有效，但文件指针位于EOF

XCOPY必须在不实际读取所有数据的情况下移动文件指针，因为当我使用包含0.5 GB的big.txt时，它仍然是“瞬时的”。如果XCOPY必须在继续之前读取所有文件，则会有很大的延迟

管 我不完全理解这一点的含义，但我相信标准管道是块缓冲的。在继续之前，XCOPY和REPLACE read最多可读取1个完整块，将管道数据的其余部分留给FINDSTR读取

我输入了一个127行的文件，其中包含4191个字节，FINDSTR在3行上输出97个字节。因此，在本例中，XCOPY似乎读取4094字节

然后我通过管道输入了一个5000字节的文件，没有任何新行，FINDSTR输出908字节，这意味着XCOPY似乎读取了4092字节

因此，管道块缓冲区必须位于4KB附近。我猜XCOPY只是简单地将文件指针移动到当前缓冲区的末尾，而不读取所有数据，但我不知道如何测试它

正如预期的那样，在使用管道时，用FIND替换FINDSTR不会改变结果-在读取管道数据后，无法将文件指针重置回管道数据的开头

---

我无法想象有任何方法可以修改XCOPY的行为或替换。。。事实就是这样

至于XCOPY和REPLACE为什么会这样做？。。。我一点也不知道。微软的“批处理”世界如此独特，以至于我很久以前就不再问为什么了

< "test.txt" (
    > nul pause
    findstr "^"
)

type "test.txt" | (
    > nul pause
    findstr "^"
)