full - get-item powershell

es el nuevo parámetro de archivo get-childItem rápido como-filter o lento como-include?

Question

EDITAR Con la esperanza de aclarar mi pregunta intrincada y engañosa ... basada en mi suposición errónea de que el archivo acepta entradas. Gracias por aclararme y señalar que es solo un parámetro de cambio; las entradas en mi ejemplo en realidad pasan a -path. Parece que esa puede ser la forma más rápida y pura de PowerShell para buscar múltiples tipos de archivos, ya que -filter acepta solo una entrada y -include es más lento.

La documentación de get-childItem dice: "Los filtros son más eficientes que otros parámetros, porque el proveedor los aplica al recuperar los objetos, en lugar de que Windows PowerShell filtre los objetos después de que se recuperan".

v3 tiene un nuevo conjunto de parámetros con un parámetro -file, probablemente destinado a excluir directorios, para que coincida con dir /a:-d cmd.exe dir /a:-d

Me gusta -incluye y a diferencia de -filter, -file acepta múltiples, como en gci -file "*.ldf","*.bak"

Así que me pregunto, y hasta ahora no he podido probar de manera confiable, si -el archivo es como -filtrar desde una perspectiva de rendimiento, es decir, "más eficiente", o más como los "otros parámetros" como -incluir. Si -file es un filtro, eso es bueno porque afaict -filter solo maneja un filtro a la vez, así que si quieres varios filtros (como * .ldf y * .bak), entonces necesitas ejecutar gci -filter dos veces o usar - incluir en su lugar. Así que me pregunto si el archivo nos permite cosechar los beneficios de eficiencia de un filtro para múltiples filtros.

Me encontré con un texto de error que me dio optimismo. El parámetro -file quiere que -path sea el directorio actual, por lo que este gci -path $path -file "*.bak","*.ldf" da un error. Push-location parece una solución viable, pero aquí estoy más interesado en el contenido del texto de error:

Get-ChildItem: No se puede convertir ''System.Object []'' al tipo ''System.String'' requerido por el parámetro ''Filter''. El método especificado no es compatible.

Llamé -file pero el error se queja de "parámetro ''Filtro''". Entonces, ¿tal vez el archivo es eficiente como un filtro? OTOH, -filtro no necesita -path para ser el directorio actual, por lo que en ese aspecto -file es más como -include.

Answer 1

solo una precisión:

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

-file es un switch parameter (como -directory is) y no acepta valores (para obtener solo archivos, use el parámetro File y omita el parámetro Directory. Para excluir archivos, use el parámetro Directory y omita el parámetro File); entonces el "*.bak","*.ldf" se pasa implícitamente a -filter como valor, y filter acepta solo string y no string[] . De ahí viene tu error.

En cuanto al rendimiento: ¿usar -file o -directory es más rápido que usar un where-object psiscontainer o ? { !$_.psiscontainer} ? { !$_.psiscontainer} porque se hace en el nivel de proveedor (sistema de archivos en este caso).