在 *nix 中，许多接受文件名作为参数的命令行应用程序也接受管道。例子：
anApplication file.txt
也适用于
anApplication | anotherApplication arguments
并且“anotherApplication”的结果被重定向到“anApplication”，因为它是一个文件
我了解到与此等效的 Windows 是“命名管道”。我想知道命令行应用程序是否必须知道命名管道才能理解它，或者是否任何接受文件作为参数的命令行应用程序都可以使用命名管道。
你把这个搞反了。准确地说：
anApplication file.txt
这anApplication以文件名file.txt作为第一个命令行参数运行。
anApplication | anotherApplication arguments
这在anApplication没有命令行参数的情况下运行。标准输出连接到作为命令行参数anotherApplication运行的标准输入。arguments这在 Windows 上与在 Unix 版本上完全相同。命名管道是一个完全不同的操作系统特性。
命名管道是一个目录条目，看起来像一个文件，但它的作用就像一个数据流，您可以将输出和输入附加到该数据流。
Windows 上的命名管道与您所说的完全不同。命名管道实际上是帮助在 Windows 上构建服务器应用程序的工具，大致相当于“Unix 域套接字”。
在您的情况下，anApplication在这种情况下是否有效取决于应用程序在命令行上没有文件名的情况下执行时的反应。（我说的是您描述中的排列；正如另一个答案所指出的那样，命令行是向后的。）如果应用程序stdin在没有命令行的情况下从启动时开始读取，那么这种外壳管道排列将起作用。相反，如果应用程序在没有文件名的情况下启动时打印帮助消息并退出，则此 shell 管道将不起作用。
请注意，这是 cmd.exe 的语法。
这种管道重定向应该适用于任何程序，因此要回答您的具体问题，如果程序是标准控制台应用程序，则不需要特殊代码。
有一个警告 - 如果程序通过运行时 API 的特殊键盘监视形式获取输入，那么重定向将不起作用。
AFAIK 它在 Windows 下的工作方式与在 UNIX 下的工作方式相同。我想一些更高级的 Win32 控制台 API 函数可能会绕过这个，但你必须阅读文档。