Comandos de la vieja escuela

Siempre tenga en cuenta que mientras PowerShell tiene comandos llamados dir y cd, no son los viejos comandos de MS-DOS. Son simplemente alias o apodos, a comandos de PowerShell. Eso significa que tienen una sintaxis diferente.

Puede ejecutar la ayuda para el comando dir (o cualquier otro alias) para ver el nombre del comando real y su sintaxis adecuada.

",{"_231":232,"_43":44,"_47":48,"_45":46,"_65":66,"_233":234,"_264":229},"previewContent","

Tabla de contenidos

\n El gran libro de “trucos” de PowerShell\n
\n Formato a la derecha\n
\n ¿Dónde está el comando <SuNombreAqui>? He instalado la última versión de PowerShell y no puedo encontrarlo!\n
\n PowerShell.exe no es PowerShell\n
\n Acumulando la salida en una función\n
\n ForEach vs ForEach vs ForEach\n
\n Finalización con Tab\n
\n -Contains y -Like son diferentes\n
\n No puede tener lo que no se tiene\n
\n -Filter y la diversidad de valores\n
\n No todo produce una salida\n
\n Una página HTML a la vez, por favor\n
\n [Sangriento] {Horrible} (Puntuación)\n
\n No+Concatene+Strings\n
\n $ no forma parte del nombre de la variable\n
\n Utilizar la canalización (pipeline), no una matriz\n
\n Backtick, Grave Accent, Escape\n
\n Una multitud no es un individuo\n
\n Comandos de la vieja escuela\n
\n Propiedades vs. Valores\n
\n Variables Remotas\n
\n New-Object PSObject vs. PSCustomObject\n
- \n New-Object PSObject en v1.0\n
- \n New-Object en PS 2.0\n
- \n PSCustomObject en PowerShell v3.0\n
\n
\n Ejecutando algo como el “usuario actualmente conectado”\n
\n Comandos que necesitan un perfil de usuario pueden fallar cuando se ejecuta de forma remota\n
\n Escribiendo en SQL Server\n
\n Obtener tamaños de carpetas\n

El gran libro de “trucos” de PowerShell

\n\n

Por Don Jones (mayormente)

\n\n

PowerShell está lleno de “trucos” - pequeñas cosas que a veces se interponen en su camino y son difíciles de averiguar por su cuenta. Este breve libro está destinado a ayudarle a resolverlos y evitarlos.

\n\n

Esta guía se publica bajo la licencia Creative Commons Attribution-NoDerivs 3.0 Unported. Los autores le animan a redistribuir este archivo lo más ampliamente posible, pero le solicitan que no modifique el documento original.

\n\n

Obteniendo el código El módulo EnhancedHTML2 mencionado en este libro puede encontrarse en PowerShell Gallery. Esa página incluye las instrucciones de descarga. PowerShellGet es necesario y se puede obtener de PowerShellGallery.com

\n\n

¿Ha sido útil este libro? El (los) autor (es) le pide (n) que haga una donación deducible de impuestos (en los EE.UU., consulte sus leyes si vive en otro lugar) de cualquier cantidad a The DevOps Collective para apoyar su trabajo.

\n\n

** Revise las actualizaciones! ** Nuestros ebooks se actualizan a menudo con contenido nuevo y corregido. Los hacemos disponibles de dos maneras:

\n\n

Nuestra rama principal GitHub organization, con un repositorio para cada libro. Visite https://github.com/devops-collective-inc/
En LeanPub, donde se pueden descargar como PDF, EPUB, o MOBI (login requerido), y “comprar” los libros haciendo una donación a DevOps. También puede elegir recibir notificaciones de actualizaciones. Visite https://leanpub.com/u/devopscollective

\n\n

GitBook y LeanPub generan la salida del formato PDF ligeramente diferente, por lo que puede elegir el que prefiera. LeanPub también le puede notificar cada vez que liberamos alguna actualización. Nuestro repositorio de GitHub es el principal; los repositorios en otros sitios suelen ser sólo espejos utilizados para el proceso de publicación. LeanPub siempre contiene la más reciente “publicación liberada” de cualquier libro.

\n\n\n

Formato a la derecha

\n\n

Todo el mundo se encuentra con esto. Comienza escribiendo un comando verdaderamente impresionante.

\n\n\n

\n\n\n

Y luego piensa, “Wow, esto quedaría muy bien en un archivo HTML.”

\n\n\n

\n\n\n

¿¡¿¡¿Un momento QUÉ?!?!?

\n\n

Sucede todo el tiempo. Si desea una manera fácil de recordar lo que no se debe hacer, es esto: nunca canalice (enviar al pipeline) la salida de un comando de formato. Esa no es toda la verdad (llegaremos a toda la verdad en un momento), pero si sólo quiere una respuesta rápida, eso es todo. En la comunidad, lo llamamos la regla del “formato a la derecha”, porque tiene que ver con mover su comando Format al extremo derecho de la línea de comandos. Es decir, el comando Format va al final, y nada más viene después de él.

\n\n

La razón es que todos los comandos de formato producen códigos de salida internos especiales, que están destinados a generar una visualización en pantalla. Canalizar esos códigos (enviarlos al pipeline) a cualquier otro comando - ConvertTo-HTML, Export-CSV, lo que sea – solo hará que se obtenga una salida ilegible.

\n\n

De hecho, hay algunos comandos que pueden venir después de un comando de formato en la canalización (pipeline):

\n\n

Out-Default. Técnicamente siempre está al final de la canalización (pipeline), aunque sea “invisible”. Es el encargado de redirigir la salida al Host. Por eso es que vemos siempre la salida en pantalla.
Out-Host también entiende la salida de los comandos de formato, porque Out-Host es la forma en la que los códigos de formato obtienen la información de lo que se debe mostrar en pantalla.
Out-Printer también entiende los códigos de formato de salida y además, construye una página impresa que se vería exactamente como la salida normal en pantalla.
Out-File, como Out-Printer, redirecciona la salida en pantalla, pero esta vez a un archivo de texto en disco.
Out-String utiliza los códigos de formato de salida y produce una cadena simple que contiene el texto que de otro modo habría aparecido en pantalla.

\n\n

Aparte de esas excepciones -y de ellas, usualmente sólo se utiliza Out-File- no se puede canalizar la salida de un comando Format a otro comando si desea obtener cualquier cosa que parezca útil.

\n\n\n

¿Dónde está el comando <SuNombreAqui>? He instalado la última versión de PowerShell y no puedo encontrarlo!

\n\n

Una cosa difícil es entender que hay un cierto número de comandos que vienen con PowerShell y otros que simplemente no vienen.

\n\n

Cada nueva versión de PowerShell incluye al menos algunos nuevos comandos. Por ejemplo, Start-Job apareció por primera vez en PowerShell v2, mientras que Invoke-AdWorkflow fue introducido en PowerShell v3.

\n\n

Lo que confunde a la gente es que una nueva versión de PowerShell también tiende a corresponder con una nueva versión del sistema operativo Windows. Y el Sistema Operativo viene con cientos de comandos. Por ejemplo, puede haber utilizado Get-SmbShare por primera vez en Windows Server 2012, que incluye PowerShell v3. Pero Get-SmbShare es parte del sistema operativo, no parte de PowerShell. Es decir, no tendrá Get-SmbShare en cada sistema que tenga PowerShell v3 o posterior, porque el comando no es una “característica de PowerShell “, es una “característica de Windows”.

\n\n

Así que… ¿De dónde se obtienen los comandos?

\n\n

Normalmente, los comandos son parte de algún producto. ¿Necesita los comandos de Exchange Server? Instale las herramientas de administración de Exchange Server. ¿Necesita los comandos de Windows Server 2012? Instale el kit de herramientas de administración remota del servidor (RSAT), que contiene las herramientas de administración del servidor.

\n\n\n

PowerShell.exe no es PowerShell

\n\n

Es importante entender que Windows PowerShell, detrás de escenas es en realidad un motor. Usted como un simple ser humano no puede interactuar directamente con PowerShell.

\n\n

En su lugar, necesita una aplicación Host. Un Host incrusta el motor internamente, y luego le da una manera de interactuar con él. Por ejemplo, powershell.exe es una aplicación Host. Se construye alrededor de la misma consola de consola de Windows (conhost.exe) a través de la antigua shell de línea de comandos cmd.exe, pero incrustando el motor PowerShell. Se escriben los comandos y el Host los envía al motor para su ejecución. El Host también es responsable de mostrar cualquier resultado. En este caso, en pantalla.

\n\n

¿Por qué es importante esta distinción?

\n\n

Porque diferentes Hosts pueden comportarse de diferentes maneras. Por ejemplo, el PowerShell ISE se comporta un poco diferente que el Host de la consola, y ambos se comportan de manera muy diferente de Active Directory Administration Center, otro host de PowerShell.

\n\n\n

Acumulando la salida en una función

\n\n

Esto es un truco un poco “avanzado”, pero es uno en que muchos desarrolladores experimentados caen. Aquí hay un ejemplo, sólo para demostrar el punto (no es funcional, ya que el comando utilizado es ficticio):

\n\n\n

\n\n\n

El problema es que la función puede generar múltiples objetos de salida, y el programador está acumulándolos en la variable de $output. Esto significa que esta función no emitirá nada hasta que su ejecución esté completamente terminada. No es así como los comandos PowerShell (y las funciones) suelen estar diseñados para funcionar.

\n\n

Los comandos de PowerShell normalmente deben enviar cada objeto a la canalización (pipeline), uno a la vez, apenas esos objetos estén listos. Esto permite que la canalización (pipeline) acumule la salida, e inmediatamente la pase a lo largo de la siguiente función o comando en la canalización (pipeline). Así funcionan los comandos en PowerShell. Ahora, siempre hay excepciones. Sort-Object, por ejemplo, tiene que acumular su salida, porque en realidad no puede ordenar nada hasta que tenga todos los elementos. Es por esto que se le llama un comando _blocking, porque “bloquea” la canalización (pipeline) completamente hasta que se produce su salida. Pero eso es una excepción.

\n\n

Normalmente esto es muy fácil de solucionar, simplemente enviando a la canalización (pipeline) directamente en lugar de acumular:

\n\n\n

\n\n\n\n

ForEach vs ForEach vs ForEach

PowerShell tiene comandos de aspecto similar que pueden confundir, especialmente a los recién llegados. Por ejemplo, usted tiene dos entidades ForEach:

\n\n

El Cmdlet ForEach-Object, que tiene un alias ForEach (también tiene el alias %). Está destinado a funcionar en la canalización (pipeline), y utiliza un parámetro de proceso que acepta un ScriptBlock.
La declaración ForEach. Tiene una sintaxis específica, no está destinado a ser utilizado en la canalización (pipeline) y no tiene un alias.

\n\n

Aquí están los tres en acción, en un ejemplo muy simple:

\n\n\n

\n\n\n

La gran diferencia es que, en la canalización (pipeline), ForEach-Object procesa un objeto a la vez. Esto significa que puede ser más lento, ya que ese ScriptBlock debe interpretarse en cada iteración. También tiende a usar menos memoria, ya que los objetos fluyen por la canalización (pipeline) uno a la vez y no tienen que ser agrupados en una variable primero.

\n\n

La declaración ForEach tiende a ser más rápida, pero a menudo tiene más sobrecarga de memoria, ya que tiene que iterar sobre toda la colección de objetos a la vez, en lugar de transmitir objetos de uno en uno cada vez.

\n\n

Ambos usan una sintaxis parecida, pero hay diferencias. Es importante entender que no son los mismos comandos, y que se ejecutan de manera diferente. Es confuso porque “ForEach” es tanto un alias como una declaración de Scripting. El Shell determina qué se está utilizando mirando el contexto en el que lo está utilizando.

\n\n\n

Finalización con Tab

Es triste y sorprendente ver cómo pocas personas confían en la terminación con la tecla Tab, tanto en el PowerShell ISE como en la ventana de la consola.

\n\n

Cuando se completa con Tab, nunca digitara comandos o nombres de parámetros incorrectos
Para muchos valores de parámetros que son listas estáticas o listas de fácil consulta, la terminación con Tab (especialmente en v3 y posteriores) puede completar los valores de dichos parámetros
La terminación con Tab hace que los nombres de Cmdlet largos sean mucho más fáciles de escribir, sin necesidad de conocer un alias de difícil o tener que memorizar el nombre completo.

\n\n

Mantenga el hábito de usar la terminación con Tab todo el tiempo que sea posible. Le garantizará cometer menos errores.

\n\n\n

-Contains y -Like son diferentes

\n\n

Si tuviera un centavo por cada vez que he visto esto:

\n\n\n

\n\n\n

Entiendo cómo sucede. El operador -Contains parece que debería comprobar si el nombre de un proceso contiene las letras “notepad”. Pero eso no es lo que hace.

\n\n

El enfoque correcto es utilizar el operador -Like, que de hecho hace una comparación de cadena con comodines:

\n\n\n

\n\n\n

Voy a dejar pasar la idea de que la respuesta realmente correcta es ejecutar Stop-Process -Name *notepad *, porque estaba apuntando a un ejemplo simple aquí. Pero … no piense demasiado. A veces un script en un bucle foreach no es el mejor enfoque.

\n\n

Así que de todos modos, ¿qué hacen -Contains (y su amigo, -NotContains) en realidad? Son similares a los operadores -In y -NotIn introducidos en PowerShell v3. Estos operadores pueden causar un poco de confusión. Lo que hacen es comprobar si una colección de objetos contiene un único objeto dado. Por ejemplo:

\n\n\n

\n\n\n

De hecho, este ejemplo es probablemente la mejor manera de verlo funcionar. El truco es que, cuando se utiliza un objeto complejo en lugar de un valor simple (como lo hice en ese ejemplo), -Contains e -In buscan en todas las propiedades del objeto para encontrar una coincidencia. Si piensa en algo como un proceso, ellos siempre estarán cambiando. De cuando en cuando, la CPU y la memoria de un proceso, pueden ser diferentes.

\n\n\n

\n\n\n

En este ejemplo, he iniciado el bloc de notas. He puesto su objeto de proceso en $single_proc, y se puede ver que he verificado que estaba allí. Pero cuando ejecuto Get-Process para comprobar si la colección contenía mi Notepad, el resultado fue falso. Eso es porque el objeto en $single_proc está desactualizado. Notepad está en ejecución, pero ahora se ve diferente, por lo que -Contains no puede encontrarlo.

\n\n

Los operadores -in y -contains son mejores con valores simples, o con objetos que no tienen valores de propiedad que cambian constantemente. Pero no son operadores de coincidencia de cadenas de caracteres comodines. Use-like (o -notlike) para eso.

\n\n\n

No puede tener lo que no se tiene

\n\n

¿Puede ver lo que está mal?

\n\n\n

\n\n\n

Quiero decir, estoy bastante seguro de que tengo algunos servicios en ejecución. Se supone que algo se debía mostrar.

\n\n

Si no ve la respuesta de inmediato - o no la ve - es un buen momento para hablar acerca de cómo solucionar problemas con algunas líneas de comandos. Para empezar, como siempre digo, retrocediendo un paso. Elimine el último comando, y vea si eso hace alguna diferencia.

\n\n\n

\n\n\n

En este caso, quité el comando Sort-Object (Sort) y no ocurrió nada diferente, así que eso no era la causa del problema. A continuación, eliminé el comando Where-Object (Where, en la sintaxis corta de v3), y ah-ha! Apareció la salida. Así que el comando Where-Object está “rompiendo” algo. Vamos a revisar lo que funcionó y a canalizarlo a Get-Member, para ver qué hay en la canalización (pipeline) después de ejecutar Select-Object.

\n\n\n

\n\n\n

OK, tengo un objeto que tiene una propiedad DisplayName y una propiedad Name.

\n\n

Y mi comando Where-Object estaba comprobando la propiedad Status. ¿Ve una propiedad Status? No, no se ve. Mi error es que quité la propiedad Status cuando no la incluí en la lista de salida del comando Select-Object. Así que el objeto no tenía nada contra qué trabajar y no devolvió nada.

\n\n

(Sí, sería mejor si PowerShell lanzara un error - “hey, pidio filtrar la propiedad Status, y no hay una!” - pero eso no así cómo funciona).

\n\n

Moraleja de la historia: prestar atención a lo que está en la canalización (pipeline). No se puede trabajar con algo que no se tiene. No siempre obtendrá un mensaje de error útil, por lo que a veces tendrá que escarbar y averiguarlo de otra manera - como retrocediendo un paso.

\n\n\n

-Filter y la diversidad de valores

Esta es una de las cosas más difíciles de acostumbrarse en PowerShell:

\n\n\n

\n\n\n

Aquí vemos tres comandos, cada uno usando un parámetro -Filter. Cada uno de esos filtros es diferente.

\n\n

Con Get-ChildItem, -Filter acepta los comodines del sistema de archivos como *.
Con Get-WmiObject, -Filter requiere una cadena, y utiliza operadores de estilo de programación (como = para la igualdad).
Con Get-ADUser, -Filter requiere un bloque de script, y acepta operadores de comparación de estilo PowerShell (como -eq para la igualdad)

\n\n

Esto es lo que pienso cuando se utiliza un parámetro –Filter. PowerShell no está procesando el filtrado. En su lugar, los criterios de filtrado se están transmitiendo a la tecnología subyacente, como el sistema de archivos, o WMI, o al directorio activo. Es esta tecnología la que decide qué tipo de criterios de filtro se van a aceptar. PowerShell es sólo el intermediario. Así que es mejor leer cuidadosamente la ayuda, y tal vez buscar ejemplos, para entender cómo la tecnología subyacente necesita que especifique su filtro.

\n\n

Sí, sería bueno si PowerShell tradujera para usted (que es realmente lo que hace Get-ADUser - el comando traduce eso en un filtro de LDAP tras bambalinas). Pero, por lo general, no lo hace.

\n\n\n

No todo produce una salida

Veo esto a menudo:

\n\n\n

\n\n\n

Si esperaba algo en la pantalla en términos de salida, estará decepcionado. El truco aquí es hacer un seguimiento de lo que cada comando produce como salida, y es allí donde hay un posible punto de confusión.

\n\n

En el mundo de PowerShell, la salida es lo que aparecería en la pantalla si ejecutamos el comando y no lo canalizamos (enviar al pipeline) a nada más. Sí, Export-CSV hace algo - crea un archivo en disco - pero en el mundo de PowerShell ese archivo no se ve en pantalla. Export-CSV no produce ninguna salida, hablando de algo que aparecería en la pantalla. Por ejemplo:

\n\n\n

\n\n\n

¿Lo ve? nada. Ya que no hay nada en la pantalla, no hay nada en la canalización (pipeline). No puede canalizar Export-CSV a otro comando, porque no hay nada que canalizar.

\n\n

Algunos comandos pueden incluir un parámetro -PassThru. Cuando lo tienen y se utiliza, harán lo que hagan normalmente, pero también pasarán sus objetos de entrada a través de la canalización (pipeline), para que luego se puedan canalizar a otra cosa. Export-CSV no es uno de esos comandos, - nunca produce una salida, por lo que nunca tendrá sentido para canalizarlo a otra cosa.

\n\n\n

Una página HTML a la vez, por favor

Esto me vuelve loco:

\n\n\n

\n\n\n

Lo que está pasando es que alguien ejecutó dos comandos, canalizando la salida de cada uno a ConvertTo-HTML, y esencialmente combinando ambas páginas HTML en un solo archivo. Lo que me realmente me vuelve loco es que Internet Explorer está bien con esa tontería.

\n\n

Los archivos HTML pueden empezar con una etiqueta de nivel superior, pero si se echa un vistazo a ese archivo verá que contiene dos:

\n\n\n

\n\n\n

He resaltado las líneas que terminan una página HTML y comienzan la siguiente. Esto es técnicamente un archivo HTML malformado. Algunos navegadores Web lo admiten (unos si, otros no), difícil de analizar si alguna vez necesita para manipular el contenido mediante programación, y … bueno, es esta mal. Es como el incesto o algo así. Inaceptable.

\n\n

Si necesita combinar varios elementos en un único archivo HTML, utilice el parámetro -Fragment de ConvertTo-HTML. Produzca sólo una parte del HTML o varias porciones de ese tipo y luego combínelas en una sola página completa. Ahhh bien. Todo el proceso al respecto de la creación de informes HTML en PowerShell lo encuentra en nuestro otro libro electrónico gratuito que viene con este.

\n\n\n

[Sangriento] {Horrible} (Puntuación)

Esto no un “truco” pero vale la pena revisarlo para que no resulte confuso. Las tuercas de PowerShell con la puntuación.

\n\n\n

\n\n\n

(Paréntesis) se utilizan para encerrar expresiones, como la expresión foreach() y en ciertos casos para resaltar alguna sintaxis declarativa. Por ejemplo el bloque param() y en el atributo [parameter()].

\n\n

[Corchetes cuadrados] se utilizan alrededor de algunos atributos, como en [CmdletBinding()], y alrededor de tipos de datos como [string]. También se utilizan para indicar arrays - como en [string[]]. Pueden aparecer en otros lugares.

\n\n

{Corchetes} casi siempre contienen código ejecutable, como en el bloque try{}, el bloque begin{} y la función en sí. También se utilizan para expresar literales de tablas hash (como @{}).

\n\n

Si el teclado tuviera algunos botones más, PowerShell no habría tenido que tener todos estos usos “incorporados” de caracteres de puntuación. Pero lo hace. En este punto, son casi una parte del “coste de entrada” del Shell, por lo que tendrá que acostumbrarse a ellos.

\n\n\n

No+Concatene+Strings

Realmente me disgusta la concatenación de cadenas. Es como obligar a alguien a acurrucarse con alguien que ni siquiera conocen. Grosero.

\n\n\n

\n\n\n

Y completamente innecesario, cuando se utilizan comillas dobles.

\n\n\n

\n\n\n

Mismo efecto al final. Usando comillas dobles, PowerShell buscará el carácter $. Cuando lo encuentre:

\n\n

Si el siguiente carácter es { entonces PowerShell llevará todo a la concordancia } como un nombre de variable, y reemplazará todo con el contenido de esa variable. Por ejemplo, poner $ {mi variable} dentro de comillas dobles reemplazará con el contenido de $ {mi variable}.
Si el siguiente carácter es un ( entonces PowerShell llevará todo a la coincidencia ) y lo ejecutara como si fuera código. Por lo que, ejecuté $wmi.serialnumber para acceder a la propiedad serialnumber del objeto que se encontraba en la variable $wmi.
De lo contrario, PowerShell tomará todos los caracteres que sean legales para un nombre de variable, hasta el primer carácter de nombre de variable ilegal, y lo reemplazará con esa variable. Así es como funciona $computer en mi ejemplo. El espacio después de la r no es legal para un nombre de variable, por lo que PowerShell sabe que el nombre de la variable se detiene en r.

\n\n

Una cosa para resaltar aquí:

\n\n\n

\n\n\n

Esto no funcionará como se esperaba. En la mayoría de los casos, $wmi será reemplazado por un nombre de tipo de objeto y .serialnumber seguirá allí. Eso ocurre porque . no es un nombre de variable legal, por lo que PowerShell deja de “observar” la variable con la letra i. Entonces, reemplaza $wmi con su contenido. Usted vio en el ejemplo anterior, el uso de $($wmi.serialnumber), que es una subexpresión y funciona. Los paréntesis hacen que su contenido se ejecute como código..

\n\n\n

$ no forma parte del nombre de la variable

Gran “trampa”.

\n\n\n

\n\n\n

¿Puede predecir el resultado?

\n\n\n

\n\n\n

Observe que el símbolo de moneda $ no forma parte del nombre de la variable. Si tiene una variable llamada example, que es como tener una caja con la palabra “ example” escrito al costado. Cuando se refiere a example significa que está hablando de la caja misma. Cuando se refiere a $ example significa que está haciendo referencia al contenido de la caja.

\n\n

Así que en mi ejemplo, he utilizado $example = 5 para poner un 5 en la caja. Luego, cree una nueva variable. El nombre de la nueva variable fue $example – que como lleva el símbolo de moneda, en realidad hace referencia al valor de la variable $example que es 5. Así que lo que ocurrió en realidad fue que se creó una variable llamada 5, que tiene asignado el valor 6, a la que se puede hacer referencia por el nombre $5.

\n\n

Difícil, ¿verdad? Lo es:

\n\n\n

\n\n\n

En ese ejemplo, utilicé el parámetro -ErrorVariable para especificar una variable en la que se almacenaría cualquier error que se produzca. El problema es, he utilizado $x cuando debería haber utilizado solo x (sin el símbolo de moneda):

\n\n\n

\n\n\n

Ahora la forma correcta. Utilizando solo x, a la que más tarde se puede acceder usando $x para obtener su contenido, es decir, cualquier error que haya sido almacenado allí.

\n\n\n

Utilizar la canalización (pipeline), no una matriz

Un error muy común cometido por programadores tradicionales que recién llegan a PowerShell:

\n\n\n

\n\n\n

Esta persona ha creado una matriz vacía en $output, y mientras recorre la lista de ordenadores y ejecuta consultas WMI, están agregando nuevos objetos de salida al contenido de la matriz. Finalmente, envía la matriz a la canalización (pipeline).

\n\n

Mala práctica. Como se ve, esto obliga a PowerShell a esperar mientras se completa la ejecución del comando. Cualquier comando subsecuente en la canalización (pipeline) se sentará a esperar con los brazos cruzados. ¿Un mejor enfoque? Utilizar la canalización (pipeline), cuyo propósito es acumular la salida por usted - sin necesidad de que usted mismo la acumule en una matriz.

\n\n\n

\n\n\n

Ahora, los comandos posteriores recibirán la salida, dejando que varios de esos comandos se ejecuten más o menos simultáneamente en la canalización (pipeline).

\n\n\n

Backtick, Grave Accent, Escape

\n\n

A menudo va a encontrarse con esto

\n\n\n

\n\n\n

No, no es un píxel muerto en el monitor o un trozo de tóner perdido en la página, es la marca de acento grave o backtick. ` Es el carácter de escape de PowerShell. En este ejemplo, está “escapando” el retorno de carro invisible al final de la línea, eliminando su propósito especial como final de línea lógica, simplemente haciendo que sea un retorno de carro literal.

\n\n

No me gusta el backtick utilizado de esta manera.

\n\n

Primero, es difícil de ver. Segundo, si se deja un espacio en blanco extra después de él, ya no estará escapando el retorno de carro, y el script se romperá:

\n\n\n

\n\n\n

Observe cuidadosamente el parámetro -computername - en este segundo ejemplo. Fíjese como se muestra un color incorrecto para un nombre de parámetro. Ocurre porque he añadido un espacio después del backtick en la línea anterior. IMPOSIBLE de rastrear.

\n\n

Y el backtick es innecesario como carácter de continuación de línea. Permítanme explicar por qué:

\n\n

PowerShell ya le permite agregar un “Enter” en ciertas situaciones. Usted solo tiene que aprender cuáles son esas situaciones, y luego tomar ventaja de ellas. Entiendo totalmente el deseo de tener código perfectamente formateado - predico sobre eso todo el tiempo - pero no tiene que confiar en un personaje como el backtick para obtener código bien formateado.

\n\n

Sólo tiene que ser más listo.

\n\n\n

\n\n\n

Para empezar, he puesto mis comandos Get-WmiObject en una tabla hash, por lo que ahora puedo dar un formato agradable y bonito. Cada línea termina en un punto y coma, y PowerShell me permite romper la línea después de cada punto y coma. Incluso si agrego un espacio adicional o un Tab después del punto y coma, funcionará bien. Entonces hago “Splat” de esos parámetros al comando Get-WmiObject.

\n\n

Después de Get-WmiObject, tengo un carácter Pipe, y PowerShell admite un “Enter” luego de un carácter Pipe.

\n\n

Usted notará al final de Select-Object que se puede utilizar una coma también.

\n\n

Así termino con un formato que parece al menos tan bueno, si no mejor, porque no tiene un backtick ` flotando por todas partes.

\n\n\n

Una multitud no es un individuo

\n\n

Un error muy común de novato:

\n\n\n

\n\n\n

Aquí, el problema es que se está tratando todo como si estuviera compuesto de un sólo un valor. Pero aqupi $computername puede contener varios nombres de equipo (eso es lo que significa ([string[]]), lo que significa que tanto $bios como $os podrían contener también varios elementos. El truco está en enumerar $computername para conseguir el resultado deseado:

\n\n\n

\n\n\n

Algunas veces también se encontrará con esto, incluso en situaciones sencillas. Por ejemplo:

\n\n\n

\n\n\n

PowerShell v2 no reaccionará tan bien, pero en PowerShell v3, la variable dentro de comillas dobles $procs es una variable que contiene varios objetos. PowerShell los enumera implícitamente, además de buscar una propiedad llamada name. Fíjese en “.name” al final de la cadena - PowerShell no hizo nada con eso.

\n\n

Es probable que mejor desee enumerar así:

\n\n\n

\n\n\n\n

Comandos de la vieja escuela

\n\n\n

Puede ejecutar la ayuda para el comando dir (o cualquier otro alias) para ver el nombre del comando real y su sintaxis adecuada.

\n\n\n

Propiedades vs. Valores

\n\n

1 $names = Get-ADComputer -filter * |\n2  Select-Object -Property Name\n3  \n4  Get-CimInstance -Class Win32_BIOS -ComputerName $names \n

\n\n\n\n

¿Sabe por qué esto no funcionará? Porque el resultado de Get-ADComputer es un objeto que tiene propiedades. Usted probablemente sabía eso. Pero el resultado de Select-Object es también un objeto que tiene propiedades. Específicamente, en este caso, es un objeto “ADComputer “ seleccionado, que tiene una sola propiedad: Name.

\n\n

Observe la ayuda del comando Get-CimInstance. El parámetro -ComputerName acepta objetos de tipo String. Así lo la ayuda. Pero un objeto ADComputer no es lo mismo que una cadena. La propiedad Name que se ha seleccionado contiene cadenas, pero no es una cadena en sí. Esto es una distinción enorme y es mejor no olvidarse de ello.

\n\n

Piense en una propiedad como una caja. Esa caja puede contener cosas, pero es una cosa en y por sí misma, también. En este caso, la caja se denomina Name y contiene cadenas. Pero no se puede “empujar” toda la caja en algo que sólo estaba esperando Strings. “Hey, quería un String, no toda la caja”

\n\n

Ahora piense en un Fax. ¿Recuerda esas máquinas? Recibían y transmitían páginas. Ahora suponga que tiene un sobre lleno de páginas. No se puede “empujar” el sobre en la máquina de fax y esperar resultados correctos. En esa analogía, el sobre es una propiedad, y las páginas dentro de ella son valores. Para lograr transmitir las páginas primero debe sacarlas del sobre.

\n\n

Lo que quiere hacer en este caso es extraer las cadenas (Strings) de la caja, y Select-Object ofrece una manera de hacer eso:

\n\n

1 $names = Get-ADComputer -filter * |\n2  Select-Object -ExpandProperty Name\n3  \n4  Get-CimInstance -Class Win32_BIOS -ComputerName $names\n

\n\n\n\n

¿Ve la diferencia? -ExpandProperty obtiene sólo el contenido de la propiedad especificada, en lugar de devolver un objeto que sólo tiene esa propiedad. ¿Quiere una manera sencilla de probar esto en el shell? Ejecute este par de comandos:

\n\n

1 Get-Service | Select -Property Name | Get-Member\n2 Get-Service | Select -ExpandProperty Name | Get-Member\n

\n\n\n\n\n

Variables Remotas

\n\n

Cuando utilice PowerShell Remoting, debe recordar que se trata de dos o más equipos que no comparten información entre ellos. Por ejemplo, el siguiente comando funcionará correctamente en su equipo local:

\n\n

1 $f1 = 'D:\\Scripts\\folder1'\n2 $f2 = 'D:\\Scripts\\folder2'\n3 Copy-Item -Path $f1 -Recurse -Destination $f2 -Verbose -F\\\n4 orce\n

\n\n\n\n

Sin embargo, si intenta ejecutar el comando Copy-Item en un equipo remoto, se producirá un error:

\n\n

 1  $f1 = \"D:\\Scripts\\folder1\"\n 2  $f2 = \"D:\\Scripts\\folder2\"\n 3 \n 4  Invoke-Command -ComputerName MemberServer -ScriptBlock {\\\n 5 Copy-Item -Path $f1 - Recurse -Destination $f2 -Verbose -\\\n 6 Force}\n 7  \n 8  Cannot bind argument to parameter 'Path' because it is n\\\n 9 ull.\n10  + CategoryInfo : InvalidData: [:] [Copy-Item], Parameter\\\n11 BindingValidationException\n12  + FullyQualifiedErrorId : ParameterArgumentValidationErr\\\n13 orNullNotAllowed,Microsoft.PowerShell.Commands.CopyItemCo\\\n14 mmand\n15  + PSComputerName : MemberServer\n

\n\n\n\n

El problema es que $f1 y $f2 se definen en su equipo local, pero no en el equipo remoto. El bloque de secuencia de comandos enviado a Invoke-Command no se evalúa en su computadora, simplemente se pasa como está (as-is).

\n\n

Hay dos posibles soluciones. La primera es simplemente incluir las definiciones de variables en el bloque de secuencia de comandos:

\n\n

1  Invoke-Command -ComputerName MemberServer -ScriptBlock {\n2  $f1 = \"D:\\Scripts\\folder1\"\n3  $f2 = \"D:\\Scripts\\folder2\"\n4  Copy-Item -Path $f1 -Recurse -Destination $f2 -Verbose -\\\n5 Force\n6  }\n

\n\n\n\n

Otra técnica, disponible en PowerShell v3 y posterior, es utilizar el designador de variable $using. PowerShell pre-escanea el bloque de secuencia de comandos y pasará los valores de la(s) variable(s) local(es) al (los) equipo(s) remoto(s).

\n\n

1  $f1 = \"D:\\Scripts\\folder1\"\n2  $f2 = \"D:\\Scripts\\folder2\"\n3  \n4  Invoke-Command -ComputerName MemberServer -ScriptBlock {\n5  Copy-Item -Path $using:f1 -Recurse -Destination $using:f\\\n6 2 -Verbose -Force}\n

\n\n\n\n

El uso de la sintaxis especial $using: es lo que hace que esta versión del comando funcione.

\n\n\n

New-Object PSObject vs. PSCustomObject

A menudo hay cierta confusión en lo que respecta a las diferencias entre el uso de nuevo objeto PSObject y PSCustomObject, así como el funcionamiento de ambos.

\n\n

Cualquiera de los dos se puede utilizar para formar un conjunto de valores en una colección de objetos PowerShell y agruparlos en una sola entidad. Asimismo, ambas formas darán salida a los datos como NoteProperties en los tipos de objeto System.Management.Automation.PSCustomObject. Así que ¿cuál es la gran diferencia entre ellos?

\n\n

Para empezar, el Cmdlet New-Object fue introducido en PowerShell v1.0 y ha pasado por una serie de cambios, mientras que el uso de la clase PSCustomObject vino más tarde en la versión 3.0. Para los sistemas que utilicen PowerShell v2.0 o anterior, se debe utilizar New-Object. La diferencia clave entre la versión 2.0 y la versión 1.0 desde un punto de vista administrativo es que 2.0 permite el uso de tablas hash. Por ejemplo:

\n\n

New-Object PSObject en v1.0

\n\n

 1 $Path = \"c:\\scripts\"\n 2 $Directory = Get-Acl -Path $Path\n 3 \n 4 ForEach ($Dir in $Directory.Access){\n 5 \n 6     $DirPermissions = New-Object -TypeName PSObject\n 7     $DirPermissions | Add-Member -MemberType NoteProperty\\\n 8  -Name Path -Value $Path\n 9     $DirPermissions | Add-Member -MemberType NoteProperty\\\n10  -Name Owner -Value $Directory.Owner\n11     $DirPermissions | Add-Member -MemberType NoteProperty\\\n12  -Name Group -Value $Dir.IdentityReference\n13     $DirPermissions | Add-Member -MemberType NoteProperty\\\n14  -Name AccessType -Value $Dir.AccessControlType\n15     $DirPermissions | Add-Member -MemberType NoteProperty\\\n16  -Name Rights -Value $Dir.FileSystemRights\n17 \n18     $DirPermissions\n19 }\n

\n\n\n\n

Con el método New-Object en PowerShell v1.0, tiene que declarar el tipo de objeto que desea crear y agregar miembros a la colección en comandos de forma individual. Sin embargo en la versión 2.0 con la capacidad de utilizar hashtables:

\n\n

New-Object en PS 2.0

\n\n

 1 $Path = \"c:\\scripts\"\n 2 $Directory = Get-Acl -Path $Path\n 3 \n 4 ForEach ($Dir in $Directory.Access){\n 5 \n 6     $DirPermissions = New-Object -TypeName PSObject -Prop\\\n 7 erty @{\n 8 \n 9     'Path' = $Path\n10     'Owner' = $Directory.Owner\n11     'Group' = $Dir.IdentityReference\n12     'AccessType' = $Dir.AccessControlType\n13     'Rights' = $Dir.FileSystemRights\n14 \n15     }\n16 \n17     $DirPermissions\n18 }\n

\n\n\n\n

Aquí está la salida:

\n\n\n

\"Note — Note theorder of output vs. order in the hash table

\n\n\n

Esta forma nos ahorra una gran cantidad de escritura al mismo tiempo que permite un script más limpio. Sin embargo ambos métodos tienen el mismo problema. La salida no está necesariamente en el mismo orden en que se ha declarado, así que si está buscando un formato determinado, puede que no funcione. PSCustomObject corrigió esto cuando fue introducido en la versión 3.0.

\n\n

PSCustomObject en PowerShell v3.0

 1 $Path = \"c:\\scripts\"\n 2 $Directory = Get-Acl -Path $Path\n 3 \n 4 ForEach ($Dir in $Directory.Access){\n 5     [PSCustomObject]@{\n 6     Path = $Path\n 7     Owner = $Directory.Owner\n 8     Group = $Dir.IdentityReference\n 9     AccessType = $Dir.AccessControlType\n10     Rights = $Dir.FileSystemRights\n11     }#EndPSCustomObject\n12 }#EndForEach\n

\n\n\n\n\n

\n\n\n

Como se puede observar, la salida siempre coincidirá con lo que se ha definido en el Hashtable. Otra ventaja de usar PSCustomObject es que la enumeración de los datos se hace más rápidamente que su contraparte New-Object. Lo único que debe tener en cuenta con PSCustomObject es que no funcionará con los sistemas que ejecutan PowerShell v2.0 o anteriores.

\n\n\n

Ejecutando algo como el “usuario actualmente conectado”

Una solicitud de PowerShell común es poder iniciar de forma remota algún código que se ejecuta bajo la cuenta del usuario que está conectado actualmente a una máquina remota o el usuario que más a menudo utiliza la máquina remota.

\n\n

Esto es realmente difícil, y generalmente impráctico.

\n\n

Primero, entender que Windows es inherentemente un sistema operativo multiusuario. No tiene un concepto para “el usuario actualmente conectado” porque puede haber muchos usuarios conectados. Aunque las versiones cliente de Windows no permiten técnicamente múltiples inicios de sesión interactivos, el sistema operativo base actúa como si pudiera.

\n\n

Segundo, como un sistema operativo multiusuario, el trabajo de Windows es mantener un estricto aislamiento alrededor del espacio de proceso de cada usuario. Usted no quiere que un usuario salte en el espacio de trabajo a otro, porque eso sería un gran riesgo para la seguridad y la estabilidad. Es por esto que no puede iniciar sesión como un usuario y ejecutar algo que otro usuario puede “ver”.

\n\n

Por ejemplo, una versión común de esta solicitud es para que un administrador de manera remota abra el Bloc de Notas como una ventana (pop up) en frente de los usuarios, para presentar de forma remota mensajes importantes. Por desgracia, el Bloc de Notas no es una buena aplicación de mensajería instantánea y Windows no hace que esto sea fácil. Si lo piensa con más detalle, ¿se imagina que podría hacer el malware si esto fuera posible? Sería horrible!

\n\n

Con muy pocas excepciones, realmente no se puede ejecutar algo “como otro usuario en una máquina remota”. Una excepción es si conoce el nombre de usuario y la contraseña del usuario remoto. Si lo conoce, puede iniciar una sesión de acceso remoto en la computadora mediante sus credenciales y, potencialmente, ejecutar aplicaciones en el espacio de proceso de ese usuario. Aunque eso es muy poco práctico en la mayoría de situaciones.

\n\n\n

Comandos que necesitan un perfil de usuario pueden fallar cuando se ejecuta de forma remota

\n\n

Muchos comandos actúan utilizando el perfil del usuario que ha iniciado sesión actualmente. Estos comandos a veces pueden fallar cuando los ejecuta a través de una conexión remota, como con Invoke-Command o Enter-PSSession. Por ejemplo, muchos instaladores predeterminan la creación de iconos por usuario y pueden fallar cuando se ejecutan remotamente, incluso cuando se ejecutan en un modo de “instalación silenciosa”.

\n\n

El problema es que, cuando se conecta a un equipo remoto, no está generando un entorno de usuario completo. Técnicamente no está “conectándose” a la máquina en el sentido usual. Se está autenticando, sí, pero de la misma manera que si se autenticara a una carpeta compartida. Su conexión remota no tiene un perfil de usuario completo, por lo que cualquier cosa que se espere puede obtener errores y fallar (incluso si no muestran esos errores).

\n\n

No hay solución fácil para esto, por desgracia.

\n\n\n

Escribiendo en SQL Server

Guardar datos en un servidor SQL - frente a Excel o algún otro formato - es muy fácil.

\n\n

Suponga que tiene SQL Server Express instalado localmente. Ha creado una base de datos llamada mydb y una tabla llamada mytable. La tabla tiene dos columnas ColumnA y ColumnB, y ambas son campos de cadenas (varchar). El archivo de base de datos está ubicado en c:\\myfiles\\mydb.mdf. Esto es muy fácil de configurar en un GUI si descarga la versión de SQL Server Express “con herramientas”. Es gratis!

\n\n

 1 $cola = \"Data to go into ColumnA\"\n 2 $colb = \"Data to go into ColumnB\"\n 3 \n 4 $connection_string = \"Server=.\\SQLExpress;AttachDbFilenam\\\n 5 e=C:\\Myfiles\\mydb.mdf;Database=mydb;Trusted_Connection=Ye\\\n 6 s;\"\n 7 $connection = New-Object System.Data.SqlClient.SqlConnect\\\n 8 ion\n 9 $connection.ConnectionString = $connection_string\n10 $connection.Open()\n11 $command = New-Object System.Data.SqlClient.SqlCommand\n12 $command.Connection = $connection\n13 \n14 $sql = \"INSERT INTO MYTABLE (ColumnA,ColumnB) VALUES('$co\\\n15 la','$colb')\"\n16 $command.CommandText = $sql\n17 $command.ExecuteNonQuery()\n18 \n19 $connection.close()\n

\n\n\n\n

Puede insertar una gran cantidad de valores simplemente haciendo un bucle a través de las tres líneas que definen la sentencia SQL y ejecutarla:

\n\n

 1 $cola = @('Value1','Value2','Value3')\n 2 $colb = @('Stuff1','Stuff2','Stuff3')\n 3 \n 4 $connection_string = \"Server=.\\SQLExpress;AttachDbFilenam\\\n 5 e=C:\\Myfiles\\mydb.mdf;Database=mydb;Trusted_Connection=Ye\\\n 6 s;\"\n 7 $connection = New-Object System.Data.SqlClient.SqlConnect\\\n 8 ion\n 9 $connection.ConnectionString = $connection_string\n10 $connection.Open()\n11 $command = New-Object System.Data.SqlClient.SqlCommand\n12 $command.Connection = $connection\n13 \n14 for ($i=0; $i -lt 3; $i++) {\n15   $sql = \"INSERT INTO MYTABLE (ColumnA,ColumnB) VALUES('$\\\n16 ($cola[$i])','$($colb[$i])')\"\n17   $command.CommandText = $sql\n18   $command.ExecuteNonQuery()\n19 }\n20 \n21 $connection.close()\n

\n\n\n\n

Es igual de fácil ejecutar consultas de actualización o eliminación. Las consultas de selección usan ExecuteReader() en lugar de ExecuteNonQuery() y devuelven un objeto SqlDataReader que se puede utilizar para leer datos de cada columna o avanzar a la siguiente fila en el conjunto de resultados.

\n\n\n

Obtener tamaños de carpetas

\n\n

La gente suele preguntar cómo usar PowerShell para obtener el tamaño de una carpeta. Por ejemplo la carpeta de documentos de un usuario.

\n\n

El problema es que las carpetas no tienen un tamaño. Windows literalmente no rastrea el tamaño de los objetos de carpeta. El tamaño de una carpeta es simplemente la suma de los tamaños de los archivos en dicha carpeta, lo que significa que para obtener el tamaño de la carpeta se tiene que sumar el tamaño de los archivos.

\n\n

1 Get-ChildItem -Path <whatever> -File -Recurse |\n2 Measure-Object -Property Length -Sum\n

\n\n\n\n

Veamos un ejemplo. Primero, es necesario obtener todos los archivos, y luego sumar sus propiedades de tamaño.

\n\n

\n\n","tocStructure",[235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260,261,262,263],{"_75":76,"_43":77,"_70":-5,"_78":79,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":85,"_70":-5,"_78":86,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":89,"_70":-5,"_78":90,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":93,"_70":-5,"_78":94,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":97,"_70":-5,"_78":98,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":101,"_70":-5,"_78":102,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":105,"_70":-5,"_78":106,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":109,"_70":-5,"_78":110,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":113,"_70":-5,"_78":114,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":117,"_70":-5,"_78":118,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":121,"_70":-5,"_78":122,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":125,"_70":-5,"_78":126,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":129,"_70":-5,"_78":130,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":133,"_70":-5,"_78":134,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":137,"_70":-5,"_78":138,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":141,"_70":-5,"_78":142,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":145,"_70":-5,"_78":146,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":149,"_70":-5,"_78":150,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":153,"_70":-5,"_78":154,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":157,"_70":-5,"_78":158,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":161,"_70":-5,"_78":162,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":165,"_70":-5,"_78":166,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":169,"_43":170,"_70":-5,"_78":171,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":169,"_43":175,"_70":-5,"_78":176,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":169,"_43":178,"_70":-5,"_78":179,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":181,"_70":-5,"_78":182,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":185,"_70":-5,"_78":186,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":189,"_70":-5,"_78":190,"_71":80,"_172":-5,"_173":-5,"_83":-5},{"_75":76,"_43":193,"_70":-5,"_78":194,"_71":80,"_172":-5,"_173":-5,"_83":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]