奇怪的标准输出重定向行为答案

【问题标题】：Strange stdout redirect behavior奇怪的标准输出重定向行为
【发布时间】：2014-06-14 21:04:25
【问题描述】：

我注意到在将标准输出重定向到“名称”中包含特殊字符的文件时出现了一些奇怪的行为。

我找到的那些：

echo.>f,test 生成一个名为f 的文件，其中包含文本,test。与.、; 和<space> 相同（显然逗号会更改为任何字符）。

echo.>f.:test 生成一个名为F~000%HK 的零字节文件。输出文件名中的第一个字符对应于重定向字符和.: 大写之间的重定向“文件名”（我相信. 被忽略/删除的原因与试图创建一个名为f.... 的文件相同创建一个名为f的文件）。我不知道其余的意思是什么，因为在“文件名”之后更改文本不会改变任何内容。即echo.>f.:nope 仍然产生空文件F~000%HK。

同一件事的另一个例子； echo.>test.:test 生成一个名为 TEST~4N5 的零字节文件。

在 Batch 中，后一个示例生成具有奇怪名称的空文件的相同结果，但前一个示例生成一个名为 f 的文件，其中包含一个空行。

要添加任何解释/“异常”吗？

【问题讨论】：

第一个很简单，逗号被当作结束符，结束文件名。请改用echo.>"f,test"。我无法重现所写的其他情况，但请注意file:test 是名为test 的文件中名为test 的alternate data stream 的有效路径名file。
在我的系统上，第二种情况只是生成“系统找不到指定的路径”。这是预期的，因为我没有 F 盘。
第三种情况对我来说按预期工作，即它生成一个名为 test. 的空文件和一个备用数据流。你在什么操作系统上？
你的意思是说echo.>f.:test对于第二种情况？
@HarryJohnston，是的，只是一个错字。

标签： windows file batch-file cmd ntfs

【解决方案1】：

, ; = <space> <tab> 是标准分隔符，因此 echo.>f,test 与 echo. ,test>f 相同。您可以从打开echo 的批处理文件中看到在这种情况下实际发生的情况。（只需在重定向之前设置echo on）。重定向语法可能很棘手，因为它仅将文件作为第一个参数，并且比命令具有更高的优先级。您可以使用echo. >"f,test" 更改结果

至于echo.>test.:test - 您正在重定向到Alternate data streams（您使用的是 FAT32 还是 NTFS 。FAT32 不支持 ADS，结果可能会产生不同的结果）？使用dir /r（Vista 及以上版本提供 r 开关）或streams.exe from sysinternals，您可以检查 ADS 的状态。要查看 ADS 内容，您可以使用更多命令：

more<test.:test

以下是我知道的可以读取 ADS 的命令：FOR /F , FIND , FINDSTR ,MORE , CERTUTIL ,CLIP ,EXPAND , SORT , MOFCOMP , FTP -S , CSCRIPT , WSCRIPT

如果记事本和写字板打开一个有 ADS 的文件，它们将删除该 ADS。

【讨论】：

如果echo.>f,test 与echo. f>test 相同，那么为什么我会得到一个名为f 的文件，其中包含文本,test？我正在使用 NTFS。 /s 显示所有子目录，是这个意思吗？
你的意思是dir /R？
在您更新的答案中，我假设您的意思是“所以echo.>f,test 与echo. ,test>f 相同。”？字符是分隔符这一事实如何导致该行被这样处理？
由于重定向（>）操作的优先级高于echo，它是第一个检查参数的操作。因为它不关心,，除非它在引号中它忽略它。所以回声带走了剩下的东西-在这种情况下是,test。事实证明，回声还打印了分隔符
请注意，在启用了 echo 的批处理文件中运行 ADS 示例，仍然显示同一行（为 stdin 添加了1）H:\uprof\>echo.1>f.:test。谢谢。