get-childItem 的新-file 参数是像-filter 一样快还是像-include 一样慢？

Question

编辑希望在这里澄清我令人费解和误导的问题......基于我错误的假设 -file 接受输入。感谢您直截了当地指出这只是一个开关参数；我的示例中的输入实际上被传递给 -path。听起来这可能是搜索多种文件类型的最快的纯 powershell 方法，因为 -filter 只接受单个输入，而 -include 更慢。

get-childItem documentation 表示“过滤器比其他参数更有效，因为提供程序在检索对象时应用它们，而不是在检索对象后让 Windows PowerShell 对其进行过滤。”

v3 有一个带有 -file 参数的new parameter set，可能是为了排除目录，以匹配 cmd.exe 的dir /a:-d

与 -include 和 -filter 不同，-file 接受多个，如gci -file "*.ldf","*.bak"

所以我想知道，并且到目前为止未能可靠地测试，如果 -file 从性能角度来看就像 -filter，即“更有效”，或者更像 -include 等“其他参数”。如果 -file 是一个过滤器，那很好，因为 afaict -filter 一次只处理一个过滤器，所以如果你想要多个过滤器（如 *.ldf 和 *.bak），那么你需要运行 gci -filter 两次或使用 -改为包括。所以我想知道 -file 是否能让我们获得一个过滤器的效率优势，用于多个过滤器。

我偶然发现了一些让我感到乐观的错误文本。 -file 参数希望 -path 成为当前目录，因此 gci -path $path -file "*.bak","*.ldf" 给出错误。推送定位似乎是一种可行的解决方法，但在这里我对错误文本的内容更感兴趣：

Get-ChildItem：无法将“System.Object[]”转换为参数“Filter”所需的类型“System.String”。不支持指定的方法。

我调用了-file，但错误抱怨“参数'过滤器'”。所以也许 -file 像过滤器一样有效？ OTOH，-filter 不需要 -path 是当前目录，所以在这方面 -file 更像 -include。

Answer 1

只有一种精度：

gci -path $path -file "*.bak","*.ldf"

-file 是 switch parameter（与 -directory 一样）并且不接受值（要仅获取文件，请使用 File 参数并省略 Directory 参数。要排除文件，请使用 Directory 参数并省略文件参数）；然后"*.bak","*.ldf" 被隐式传递给-filter 作为值，filter 只接受string 而不是string[]。这就是您的错误的来源。

关于性能：使用 -file 或 -directory 比使用 where-object psiscontainer 或 ? { !$_.psiscontainer} 更快，因为它是在提供程序（在本例中为文件系统）级别完成的。