是get-childItem的新的文件参数快速像过滤器或像-include慢？ [英] is get-childItem's new -file parameter fast like -filter or slow like -include?

问题描述

希望在这里澄清我的错综复杂和误导性的问题...根据我错误的假设，文件接受输入。感谢您的设置，并指出这只是一个开关参数;我的例子中的输入实际上被传递给-path。听起来像这样可能是最快的纯PowerShell的方式来搜索多个文件类型，因为-filter只接受一个输入，而-include比较慢。

get-childItem 文档中提到过滤器比其他参数更高效，因为提供程序在检索对象时应用它们，而不是让Windows PowerShell在检索对象后过滤对象。

v3有一个新的参数集带有-file参数，可能意味着排除目录，以匹配cmd.exe的

像-include和different -filter一样，-file接受多个，如 gci -file* .ldf，*。bak

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

我偶然发现了一些让我乐观的错误文本。 -file参数希望-path是当前目录，所以这个 gci -path $ path -file* .bak，*。ldf会给出一个错误。推送位置似乎是一个可行的解决方法，但在这里我更感兴趣的错误文本的内容：
$ b

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

我调用了-file，但是错误提示Filter'。所以也许文件是有效的像一个过滤器？ OTOH，-filter不需要-path作为当前目录，所以在这方面-file更像-include。

解决方案

  gci -path $ path -file* .bak，*。ldf
  

-file 是一个 switch参数（作为 -directory 是）并且不接受值（要仅获取文件，请使用File参数并省略Directory参数要排除文件，使用Directory参数并省略File参数）;那么将*。bak，*。ldf作为值隐式传递给 -filter code> filter 只接受 string 而不是 string [] 。使用 -file 或 -directory



比使用 where-object psiscontainer 或更快{！$ _。psiscontainer} ，因为它是在提供者（在这种情况下是文件系统）级别完成的。

EDIT Hoping here to clarify my convoluted and misleading question... based on my mistaken assumption that -file accepts inputs. Thanks for setting me straight and pointing out that it's just a switch parameter; the inputs in my example actually get passed to -path. Sounds like that may be the fastest purely powershell way to search for multiple file types, since -filter accepts only a single input and -include is slower.

The get-childItem documentation says "Filters are more efficient than other parameters, because the provider applies them when retrieving the objects, rather than having Windows PowerShell filter the objects after they are retrieved."

v3 has a new parameter set with a -file parameter, probably meant for excluding directories, to match cmd.exe's dir /a:-d

Like -include and unlike -filter, -file accepts multiple, as in gci -file "*.ldf","*.bak"

So i'm wondering, and have thus far failed to reliably test, if -file is like -filter from a performance perspective, ie "more efficient", or more like the "other parameters" like -include. If -file is a filter, that's nice because afaict -filter only handles one filter at a time, so if you want multiple filters (like *.ldf and *.bak) then you need to either run gci -filter twice or use -include instead. So I'm wondering if -file lets us reap the efficiency benefits of a filter, for multiple filters.

I stumbled on some error text that's got me optimistic. The -file parameter wants -path to be the current directory, so this gci -path $path -file "*.bak","*.ldf" gives an error. Push-location seems like a viable workaround, but here I'm more interested in the content of the error text:

Get-ChildItem : Cannot convert 'System.Object[]' to the type 'System.String' required by parameter 'Filter'. Specified method is not supported.

I called -file but the error complains about "parameter 'Filter'". So maybe -file is efficient like a filter? OTOH, -filter doesn't need -path to be the current directory, so in that respect -file is more like -include.

解决方案

just one precision:

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

-file is a switch parameter (as -directory is) and doesn't accept values (To get only files, use the File parameter and omit the Directory parameter. To exclude files, use the Directory parameter and omit the File parameter); then the "*.bak","*.ldf" are implicitly passed to -filter as value, and filter accept only string and not string[]. That's where your error came from.

Regarding performance: using -file or -directory is faster than using a where-object psiscontainer or ? { !$_.psiscontainer} because it's done at provider (filesystem in this case) level.

这篇关于是get-childItem的新的文件参数快速像过滤器或像-include慢？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！