Windows PowerShell Qué no secuencias de comandos
Don Jones
Contenido
No abusar de variables
Nombres de variables significativos
Simplificar comparaciones
No interrumpir su secuencia de comandos
El bucle de bucle
No puede modo silencioso
Mostrar las secuencias de comandos
Realizados recientemente una oferta (que todavía son las siglas) para los lectores de mi ConcentratedTech.comblog: envíeme las secuencias de comandos Windows PowerShell y va a revisarlos y ofrecer alguna sugerencia se debe mejorarlos. La idea procede realmente de una encuesta mis bloggers co y ejecuté, un lector sugiere que esto podría proporcionar una manera gran, real-world puedan mejorar sus habilidades de secuencias de comandos. En los últimos meses, he observado tendencias unas como yo realizar varias sugerencias determinadas repetidamente. Por lo que ha compilado una lista de ellos para compartir con usted aquí.
Voy a primer estado, sin embargo, que cualquier secuencia de comandos que obtiene el trabajo que realiza (correctamente y sin daños complementario, del curso) es una buena secuencia de comandos. Algunas cosas que estoy sugerir pueden parecer que nitpicky y algunos de ellos son ciertamente. Sin embargo, cada uno de mis sugerencias tiene algunas ventajas claras, que intentaré señale entraré.
No tendrán ofensa si realmente está realizando algunas de las "prácticas incorrectas" que señale. Sé que un lote de personas que la secuencia de comandos en Windows PowerShell empezó secuencias de comandos con VBScript y algunos de estas "prácticas incorrectas" están realmente muy común en el mundo de VBScript. Se trata una gran oportunidad, a continuación, aprenda cómo Windows PowerShell y VBScript son un poco diferente y cómo escribir secuencias de comandos que utilicen ventajas únicas que Windows PowerShell tiene que ofrecer.
Con la dice que aquí son mis sugerencias comunes seis superiores realizados a través de los últimos meses.
No abusar de variables
Por supuesto, las variables son útiles, pero vamos a no perder. Ha sido ver gran cantidad de este tipo de secuencias de comandos:
$varfile = "c:\names.txt"
$varexists = Test-Path $varfile
if ($varexists –eq $false) {
Write-Output "The file $varfile does not exist"
break
}
$varnames = Get-Content $varfile
Hay unas prácticas que me gustaría ver modificados en un ejemplo así. En primer lugar y principalmente, es necesario cumplir toda esa información en variables. Es posible volver a escribir esta con menos variables. ¿Por qué preocuparse? Bien, el shell no es posible que ocupa cuántas variables que utilizar, pero soy un ventilador grande, grande de realizar secuencias de comandos como legible como sea posible para que alguien pueda leer la secuencia de comandos en papel o en un editor de secuencias de comandos y poder averiguar lo que hace la secuencia de comandos. Más variables incluir, el más alguien tendrá que hacer un seguimiento en su encabezado, y será menos probable le pueda saber lo que es hasta la secuencia de comandos. Si no se sabe la secuencia de comandos en papel, soy menos probable que pueda depurar la secuencia de comandos si hay un problema. Así comience por volver a escribir en este ejemplo como sigue:
$varfile = "c:\names.txt"
If ((Test-Path $varfile) –eq $false) {
Write-Output "The file $varfile does not exist"
break
}
$varnames = Get-Content $varfile
Realmente Estoy realizando es eliminar la variable de varexists $ y directamente utilizando el resultado de la ruta de la prueba. De este modo, no tener que mirar la si construir, vea varexists $ y volver atrás y averiguar qué varexists $ se supone que contienen. Es menor para mí realizar un seguimiento de mi cabeza. Observe que dejé varfile $; esto es porque utiliza esa información tres veces, si está reutilizar información varias veces, merece la pena poner en una variable.
Nombres de variables significativos
Continuando con el ejemplo anterior, recuerde siempre que los nombres de variable deben ayudarle a recordar novedades dentro de una variable. No es necesario utilizar prefijos de nombre como "var" porque el carácter $ le indica que es una variable. Nombre de hecho, prefijos como "str" para las cadenas o "int" para los enteros están anticuado ("eso por lo que 1993" que diga al que estoy impartir clases). Utilizar sólo nombres de variables sencillos. Volver a escribir el ejemplo es:
$filename = "c:\names.txt"
If ((Test-Path $filename) –eq $false) {
Write-Output "The file $filename does not exist"
break
}
$computernames = Get-Content $filename
Simplificar comparaciones
No soy un ventilador de operadores de comparación en Windows PowerShell, los como –gt, - lt, - eq y así sucesivamente. Mi falta de debilidad procede probablemente mi experiencia largo con VBScript, donde se podrían utilizar como operadores familiarizados >, < y =. Muchos de ustedes probablemente reconocen estos operadores de calificación escolar matemáticas lecciones y por lo tanto, requieren menos análisis mental al leerlos. A continuación, siempre que sea posible, me gusta evitar el uso de un operador. Y cualquier condición donde buscar algo para ser True o False es una oportunidad para librarse de un operador:
$filename = "c:\names.txt"
If (-not (Test-Path $filename)) {
Write-Output "The file $filename does not exist"
break
}
$computernames = Get-Content $filename
El cmdlet Test-Path no devuelve True o false, es es necesario comparar a True o false. Todo dentro de la si construye paréntesis necesita limitan hacia abajo en True o false. Normalmente, se utilizaría una comparación para lograr, pero si lo hay es ya generar True o false, sólo se puede utilizar esa información directamente.
Debo recalcar que el operador –not es que realmente quiero. Es más como inglés común el equivalente! = operador utilizado por muchos idiomas.
Además, debe comentar los paréntesis que estoy colocar alrededor de ruta de la prueba y su parámetro de entrada filename $. Ha empecé escribe comandos entre paréntesis porque ayuda a mí visualmente los entender como una sola unidad. Windows PowerShell usa espacios, en lugar algún carácter para separar cosas como comandos, los nombres de parámetros y valores de parámetro. Escribe la cadena de comando completo entre paréntesis me ayuda a ver todas juntas, sin necesidad de me realmente, examine los espacios y determinar donde el comando inicia y detiene.
No interrumpir su secuencia de comandos
La última sugerencia que tengo para ejecutar este ejemplo es la forma que se genera su lógica. Si el archivo no existe, interrumpirá fuera de la secuencia de comandos. Si el archivo existe, nunca ejecutar la instrucción de salto y por lo que sigue la secuencia de comandos. Siempre que sea posible, me gusta Evite utilizar break para salir de una secuencia de comandos. Debería volver a escribir en el ejemplo, nuevo, como sigue:
$filename = "c:\names.txt"
If (Test-Path $filename) {
$computernames = Get-Content $filename
# do whatever we planned to do
} else {
Write-Output "The file $filename does not exist"
}
De este modo, ha simplificado la lógica de la si construir. También ha eliminado la necesidad de utilizar la instrucción de salto, que reduce la confusión sobre lo que hace la secuencia de comandos. Soy el primero que admitir que esta sugerencia es absolutamente un nitpick, pero Creo que buenas prácticas de codificación para facilitar secuencias de comandos mejor, y definitivamente es una mejor práctica de abandonando fuera de una secuencia de comandos medio. Este tipo de construcción es más fácil de depurar y es mucho más fácil siga en papel si está examinando una secuencia de comandos y intentando averiguar qué hace.
El bucle de bucle
Varias secuencias de comandos que revisé necesitan para leer la información de un archivo de texto y recorrer cada línea del archivo. Por ejemplo, quizás desee contacto una serie de equipos, por lo que podría enumerar sus nombres, un nombre por línea en un archivo de texto. Ésta es una construcción común que he visto:
$line = 0
$names = get-content c:\names.txt
while ($line –lt $names.length) {
# do something with $names[$line]
$line++
}
Esto carga el archivo en la variable $ names y, a continuación, manualmente enumera a través de la colección como si fuese una matriz. La variable de línea $ realiza un seguimiento de la línea que se está trabajando con. Funciona correctamente, pero Estoy realizando un poco más trabajo que necesito hacer, y hacer estoy que el código un poco más difícil para alguien leer más tarde. La construcción de ForEach en Windows PowerShell es un poco más adecuada para enumerar las colecciones. (Técnicamente, Get-Content devuelve una colección, no una matriz). Pruebe en su lugar:
Foreach ($name in (Get-Content c:\names.txt))
{
# do something with $name
}
Hay unas cuantas ventajas aquí. En consonancia con Mi sugerencia anterior, estoy poner la llamada a Get-Content derecha dentro de la construcción, ya que creo que facilita un poco más claro como para lo que sucede. ForEach enumerará por toda la colección, independientemente de cuánto es. Cada vez a través, se tome el siguiente elemento en la colección y poner ese elemento en la variable de nombre de $. Por lo que el nombre de la variable representa lo que contiene, un nombre de equipo. Y que facilita la secuencia de comandos para leer y seguir.
Windows PowerShell Q & A
P ¿Hay una forma de definir un alias personalizado permanente en Windows PowerShell?
A si alguna vez ha creado un nuevo alias, probablemente haya observado que desaparece cuando cierra el shell. Por ejemplo, esto crea un nuevo d alias, que es un método abreviado para el comando Get-ChildItem:
Alias nuevo d Get-ChildItem
Pero cuando cierre el shell, se perderá el alias. El truco consiste en crear un perfil de Windows PowerShell. En la carpeta de documentos, cree una nueva carpeta denominada WindowsPowerShell. Dentro de esa carpeta, cree un archivo de texto denominado profile.ps1. En ese archivo de texto, coloque los comandos que desea ejecutar automáticamente cada vez que inicia el shell, incluyendo una nueva definición de alias. El perfil se garantiza que los comandos se ejecutarán cada vez que inicie el shell, crear un alias "permanente" que siempre está disponible en Windows PowerShell.
No necesito preocuparse acerca de qué línea se está trabajando con o mantener una variable de línea $ para realizar un seguimiento de que: la construcción de ForEach hace eso para mí. Eliminación de tres líneas de código hace que el código un poco más concisa y requiere mantener un seguimiento de cosas menos en la cabeza cuando intenta averiguar lo que hace la secuencia de comandos.
No puede modo silencioso
La uno práctica que realmente desea nip en el bud es la práctica de suprimir los errores de shell en una secuencia de comandos completa. Supongamos que está viendo una secuencia de comandos que incluye este derecho de la línea en la parte superior:
$ErrorActionPreference = "SilentlyContinue"
Detener inmediatamente.
Esto no realizar errores desaparecerán, pero suprimir ellos. Sí, ciertamente, hay ocasiones cuando se prevé y desea descartar un determinado error, como por ejemplo cuando se utiliza (WMI) para conectarse a equipos remotos que potencialmente no están disponibles. Pero hay nunca un motivo para globalmente omitir errores. Mensajes de error son útiles y señalar problemas que a veces puede corregir.
Si desea que omita errores para un cmdlet determinado, puede hacerlo agregando el parámetro de "SilentlyContinue" –EA a ese cmdlet. Si desea que omita errores para varios comandos en una fila, agregue el parámetro –EA a cada o agregue la línea de ErrorActionPreference $ inmediatamente antes de estos comandos y después los comandos, agregar:
$ErrorActionPreference = "Continue"
Esto establece el control de errores para normal.
Personalmente, no me gusta desactivar errores en absoluto a menos que me controlar esos errores yo mismo. Por ejemplo:
Trap {
# output error to a log file or something
}
Get-WmiObject Win32_Service –computerName $remote –EA Stop
En este breve ejemplo se muestra cómo el parámetro de "Stop" –EA generará excepciones true en lugar de sólo mensajes de error, darle la oportunidad para interceptarlos y controlarlos propia. Puede registrar en un archivo, mostrar una agradable mensaje de error o hacer otra cosa a tal efecto.
Mostrar las secuencias de comandos
Como dije anteriormente, algunas de ellas han sido un nitpicky bits, pero ofrecen ventajas claras que merece la pena consideración. Invito compartir sus propios scripts de Windows PowerShell. Revise un par de cada mes y registrar mis sugerencias en ConcentratedTech.com. No dude en consultar algunas de mis sugerencias anteriores y quizá incluso enviar sus propios scripts para su revisión. Esperamos auditivas!
Don Jones es cofundador de tecnología concentró. Se puede leer sugerencias sobre Windows PowerShell y otros temas de TI, así como póngase en contacto con Don, en su blog en ConcentratedTech.com.