0

EDITここで、複雑で誤解を招く質問を明確にすることを望んでいます... -file が入力を受け入れるという私の誤った仮定に基づいています。私をまっすぐに設定し、それが単なるスイッチパラメーターであることを指摘してくれてありがとう。この例の入力は、実際には -path に渡されます。-filter は単一の入力のみを受け入れ、 -include は遅いため、複数のファイルタイプを検索するための純粋なPowerShellの最速の方法のように思えます。

get-childItem のドキュメントには、「フィルターは、オブジェクトの取得後に Windows PowerShell でフィルター処理するのではなく、プロバイダーがオブジェクトの取得時にフィルターを適用するため、他のパラメーターよりも効率的です」と記載されています。

v3 には -file パラメーターを含む新しいパラメーター セットがあり、おそらくディレクトリを除外するためのもので、cmd.exe のものと一致します。dir /a:-d

-include と同様、-filter とは異なり、-file は次のように複数を受け入れます。gci -file "*.ldf","*.bak"

だから私は疑問に思っており、これまでのところ、パフォーマンスの観点から -file が -filter に似ているかどうか、つまり「より効率的」なのか、それとも -include のような「他のパラメーター」に似ているのかを確実にテストできていません。-file がフィルターの場合、afaict -filter は一度に 1 つのフィルターしか処理しないため、これは適切です。そのため、複数のフィルター (*.ldf や *.bak など) が必要な場合は、gci -filter2 回実行するか、代わりに -include を使用する必要があります。したがって、 -file を使用すると、複数のフィルターに対してフィルターの効率の利点を享受できるかどうか疑問に思っています。

楽観的になるようなエラー テキストを偶然見つけました。-file パラメータは -path を現在のディレクトリにしたいので、これgci -path $path -file "*.bak","*.ldf"はエラーになります。プッシュロケーションは実行可能な回避策のように思えますが、ここで私はエラーテキストの内容にもっと興味があります:

Get-ChildItem : 'System.Object[]' を、パラメーター 'Filter' で必要なタイプ 'System.String' に変換できません。指定された方法はサポートされていません。

-file を呼び出しましたが、「パラメータ 'Filter'」に関するエラーが表示されます。それで、おそらく -file はフィルターのように効率的ですか？OTOH、-filter は -path を現在のディレクトリにする必要がないため、その点で -file は -include に似ています。

4

1 に答える 1

3

1 つの精度のみ:

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

-fileswitch parameter(そのまま) であり、-directory値を受け入れません (ファイルのみを取得するには、File パラメーターを使用し、Directory パラメーターを省略します。ファイルを除外するには、Directory パラメーターを使用し、File パラメーターを省略します)。次に、は値として"*.bak","*.ldf"暗黙的に渡され、のみを受け入れ、 は受け入れません。それがあなたのエラーの原因です。-filterfilterstringstring[]

パフォーマンスについて:-fileまたはを使用すると、プロバイダ (この場合はファイルシステム) レベルで実行されるため、 or -directoryを使用するよりも高速です。where-object psiscontainer? { !$_.psiscontainer}

于 2012-12-07T20:38:37.780 に答える