Por varios motivos, en su mayoría relacionados con la seguridad, los scripts de PowerShell no son tan fáciles de usar y portátiles como los scripts por lotes. Sin embargo, podemos agrupar un script por lotes con nuestros scripts de PowerShell para solucionar estos problemas. Aquí, le mostraremos algunas de esas áreas problemáticas, y cómo crear un script por lotes para evitarlas.

¿Por qué no puedo simplemente copiar mi archivo .PS1 a otra computadora y ejecutarlo?

A menos que el sistema de destino haya sido preconfigurado para permitir la ejecución de secuencias de comandos arbitrarias, con los privilegios necesarios y con la configuración correcta, es probable que se encuentre con algunos problemas cuando intente hacer esto.

1. PowerShell es no asociado a la extensión de archivo .PS1 de forma predeterminada. Lo mencionamos inicialmente en nuestra serie PowerShell Geek School. Windows asocia los archivos .PS1 al Bloc de notas de forma predeterminada, en lugar de enviarlos al intérprete de comandos de PowerShell. Esto es para evitar la ejecución accidental de scripts maliciosos simplemente haciendo doble clic en ellos. Hay formas en que puede cambiar este comportamiento, pero probablemente no sea algo que desee hacer en cada computadora con la que está ejecutando sus secuencias de comandos, especialmente si algunas de esas computadoras no son suyas.
2. PowerShell no permite el uso externo ejecución de scripts de forma predeterminada. La configuración de ExecutionPolicy en PowerShell impide la ejecución de scripts externos de forma predeterminada en todas las versiones de Windows. En algunas versiones de Windows, el valor predeterminado no permite la ejecución de scripts. Le mostramos cómo cambiar esta configuración en Cómo permitir la ejecución de scripts de PowerShell en Windows 7. Sin embargo, esto también es algo que no desea hacer en cualquier computadora.
3. Algunos scripts de PowerShell no funcionarán sin Permisos de administrador. Incluso ejecutándose con una cuenta de nivel de administrador, usted todavía necesita pasar por el Control de cuentas de usuario (UAC) para realizar ciertas acciones. No queremos deshabilitar esto, pero aún es bueno cuando podemos hacerlo un poco más fácil de tratar.
4. Algunos usuarios pueden tener entornos personalizados de PowerShell.
   Probablemente no se encontrará con esto a menudo, pero cuando lo haces puede hacer que correr y solucionar problemas de tus scripts sea un poco frustrante. Afortunadamente, podemos evitar esto sin realizar ningún cambio permanente.

Paso 1: Haga doble clic para ejecutar.

Comencemos abordando el primer problema: asociaciones de archivos .PS1. No puede hacer doble clic para ejecutar archivos .PS1, pero puede ejecutar un archivo .BAT de esa manera. Por lo tanto, escribiremos un archivo por lotes para llamar al script de PowerShell desde la línea de comandos para nosotros.

Así no tenemos que volver a escribir el archivo por lotes para cada script, o cada vez que movemos un script, va a hacer uso de una variable autorreferencial para construir la ruta del archivo para el script de PowerShell. Para que esto funcione, el archivo por lotes deberá colocarse en la misma carpeta que su secuencia de comandos de PowerShell y tener el mismo nombre de archivo. Entonces, si su secuencia de comandos de PowerShell se llama "MyScript.ps1", querrá nombrar su archivo de proceso por lotes "MyScript.bat" y asegurarse de que esté en la misma carpeta. Luego, ponga estas líneas en el script por lotes:

@ECHO OFF PowerShell.exe -Command "& '% ~ dpn0.ps1'" PAUSE

Si no fuera por las otras restricciones de seguridad, eso realmente es todo lo que se necesita para ejecutar un script de PowerShell desde un archivo por lotes. De hecho, la primera y la última línea son principalmente una cuestión de preferencia; es la segunda línea la que realmente está haciendo el trabajo. Aquí está el desglose:

@ECHO OFF desactiva el eco de comandos. Esto solo evita que sus otros comandos se muestren en la pantalla cuando se ejecuta el archivo por lotes. Esta línea está oculta por el uso del símbolo at (@) frente a ella.

PowerShell.exe -Command "& '% ~ dpn0.ps1'" en realidad ejecuta el script de PowerShell. Por supuesto, se puede llamar a PowerShell.exe desde cualquier ventana CMD o archivo por lotes para iniciar PowerShell en una consola simple como siempre. También puede usarlo para ejecutar comandos directamente desde un archivo por lotes, incluyendo el parámetro -Command y los argumentos apropiados. La forma en que esto se utiliza para apuntar a nuestro archivo .PS1 es con la variable especial% ~ dpn0. Ejecutar desde un archivo por lotes,% ~ dpn0 evalúa la letra de la unidad, la ruta de la carpeta y el nombre del archivo (sin extensión) del archivo por lotes. Como el archivo por lotes y el script de PowerShell estarán en la misma carpeta y tendrán el mismo nombre,% ~ dpn0.ps1 se traducirá a la ruta completa del archivo del script de PowerShell.

PAUSE simplemente detiene la ejecución del lote y espera la entrada del usuario. En general, es útil tenerlo al final de los archivos de proceso por lotes, de modo que tenga la oportunidad de revisar cualquier salida de comando antes de que la ventana desaparezca. A medida que avanzamos en las pruebas de cada paso, la utilidad de esto se hará más obvia.

Entonces, se configura el archivo de proceso por lotes básico. Para fines de demostración, este archivo se guarda como "D: Script Lab MyScript.bat" y hay un "MyScript.ps1" en la misma carpeta. Veamos qué sucede cuando hacemos doble clic en MyScript.bat.

Obviamente, el script de PowerShell no se ejecutó, pero eso es de esperar; después de todo, solo hemos abordado el primero de nuestros cuatro problemas. Sin embargo, aquí se muestran algunos bits importantes:

1. El título de la ventana muestra que el script por lotes inició PowerShell correctamente.
2. La primera línea de salida muestra que se está utilizando un perfil de PowerShell personalizado. Este es el problema potencial n. ° 4, mencionado anteriormente.
3. El mensaje de error muestra las restricciones de ExecutionPolicy vigentes. Ese es nuestro problema n. ° 2.
4. La parte subrayada del mensaje de error (que se realiza de forma nativa mediante el resultado de error de PowerShell) muestra que el guión por lotes estaba apuntando correctamente al guión de PowerShell deseado (D: Script Lab MyScript.ps1). Por lo tanto, al menos sabemos que mucho está funcionando correctamente.

El perfil, en este caso, es un script simple de una línea usado para esta demostración para generar resultados cada vez que el perfil está activo. Puede personalizar su propio perfil de PowerShell para hacer esto también, si desea probar estos scripts usted mismo. Simplemente agregue la siguiente línea a su script de perfil:

Write-Output '¡Perfil de PowerShell personalizado en vigencia!'

ExecutionPolicy en el sistema de prueba aquí está configurado como RemoteSigned. Esto permite la ejecución de scripts creados localmente (como el script de perfil), al tiempo que bloquea los scripts de fuentes externas a menos que estén firmados por una autoridad de confianza. Para fines de demostración, se utilizó el siguiente comando para marcar MyScript.ps1 como procedente de una fuente externa:

Add-Content-Path 'D:  Script Lab' MyScript.ps1 '-Value "[ZoneTransfer]' nZoneId = 3 "-Stream 'Zone.Identifier'

Eso establece el flujo de datos alternativo Zone.Identifier en MyScript.ps1 para que Windows piense que el archivo proviene de Internet. Se puede revertir fácilmente con el siguiente comando:

Clear-Content -Path 'D:  Script Lab  MyScript.ps1' -Stream 'Zone.Identifier'

Paso 2: Cómo desplazarse por ExecutionPolicy.

Getting alrededor de la configuración de ExecutionPolicy, desde CMD o un script por lotes, en realidad es bastante fácil. Solo modificamos la segunda línea de la secuencia de comandos para agregar un parámetro más al comando PowerShell.exe.

PowerShell.exe -ExecutionPolicy Bypass -Command "& '% ~ dpn0.ps1'"

El parámetro -ExecutionPolicy puede ser utilizado para modificar la ExecutionPolicy que se usa cuando genera una nueva sesión de PowerShell. Esto no persistirá más allá de esa sesión, por lo que podemos ejecutar PowerShell de esta manera siempre que lo necesitemos sin debilitar la postura general de seguridad del sistema. Ahora que hemos solucionado eso, hagámoslo:

Ahora que el script se ha ejecutado correctamente, podemos ver lo que realmente hace. Nos permite saber que estamos ejecutando el script como un usuario limitado. De hecho, el script está siendo ejecutado por una cuenta con permisos de Administrador, pero el Control de cuentas de usuario se interpone en el camino. Aunque los detalles de cómo el script está comprobando el acceso del Administrador están fuera del alcance de este artículo, aquí está el código que se está utilizando para la demostración:

if (([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity] :: GetCurrent ()). IsInRole ([Security.Principal.WindowsBuiltInRole] "Administrator")) {Write-Output '¡Ejecutando como administrador!'} Else {Write-Output 'Running Limited!'} Pausa

También notará que ahora hay dos operaciones de "Pausa" en la salida del script: una desde el script de PowerShell y otra desde el archivo por lotes. La razón para esto será más evidente en el próximo paso.

Paso 3: Obtener acceso de administrador.

Si su script no ejecuta ningún comando que requiera elevación, y usted está seguro de que no tendrá preocuparse por los perfiles personalizados de cualquier persona en el camino, puede omitir el resto de esto. Sin embargo, si está ejecutando algunos cmdlets de nivel de administrador, necesitará esta pieza.

Desafortunadamente, no hay forma de activar el UAC para la elevación desde un archivo de proceso por lotes o una sesión de CMD. Sin embargo, PowerShell nos permite hacer esto con Start-Process. Cuando se utiliza con "-Verb RunAs" en sus argumentos, Start-Process intentará iniciar una aplicación con permisos de Administrador. Si la sesión de PowerShell no está elevada, esto activará un aviso de UAC. Para usar esto desde el archivo de proceso por lotes para iniciar nuestro script, terminaremos generando dos procesos de PowerShell: uno para iniciar Start-Process y otro, iniciado por Start-Process, para ejecutar el script. La segunda línea del archivo por lotes debe cambiarse a esto:

PowerShell.exe -Command "& {Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy Bypass -File" "% ~ dpn0.ps1" "' - Verb RunAs} "

Cuando se ejecuta el archivo por lotes, la primera línea de salida que veremos proviene del script de perfil de PowerShell. Luego, habrá una solicitud de UAC cuando Start-Process intente iniciar MyScript.ps1.

Después de hacer clic en el indicador de UAC, se generará una nueva instancia de PowerShell. Debido a que esta es una nueva instancia, por supuesto, volveremos a ver el aviso del script de perfil. Luego, se ejecuta MyScript.ps1 y vemos que estamos efectivamente en una sesión elevada.

Y también está la razón por la que tenemos dos pausas aquí. Si no fuera por el script de PowerShell, nunca veríamos el resultado del script: la ventana de PowerShell simplemente aparecería y desaparecería tan pronto como el script se ejecute. Y sin la pausa en el archivo por lotes, no podríamos ver si hubo algún error al iniciar PowerShell en primer lugar.

Paso 4: Moverse por perfiles personalizados de PowerShell.

Deshagámonos de ese desagradable aviso de perfil personalizado ahora, ¿de acuerdo? Aquí, apenas es una molestia, pero si el perfil de PowerShell de un usuario cambia las configuraciones, variables o funciones predeterminadas de formas que quizás no haya previsto con su secuencia de comandos, pueden ser realmente molestas. Es mucho más simple ejecutar su script sin el perfil completo, por lo que no tiene que preocuparse por esto. Para hacer eso, solo tenemos que cambiar la segunda línea del archivo por lotes una vez más:

PowerShell.exe -NoProfile -Command "& {Start-Process PowerShell.exe -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File" "% ~ dpn0.ps1" "'-Verb RunAs}"

Al agregar el parámetro -NoProfile a ambas instancias de PowerShell que inicia el script, significa que el script de perfil del usuario se omitirá por completo en ambos pasos y nuestro script de PowerShell se ejecutará en un entorno predeterminado bastante predecible. Aquí puede ver que no hay un aviso de perfil personalizado en ninguno de los shells generados.

Si no necesita derechos de administrador en su secuencia de comandos de PowerShell y se saltó el Paso 3, puede prescindir de la segunda instancia de PowerShell y la segunda línea de su archivo de proceso por lotes debería tener el siguiente aspecto:

PowerShell.exe -NoProfile -ExecutionPolicy Bypass -Command "& '% ~ dpn0.ps1'"

La salida se verá así:

( Por supuesto, para las secuencias de comandos que no son de administrador, podría prescindir de una pausa de final de secuencia de comandos en su secuencia de comandos de PowerShell en este momento, ya que todo se captura en la misma ventana de consola y se mantendría allí por la pausa al final de la misma. archivo por lotes de todos modos.)

Archivos de proceso por lotes terminados.

Dependiendo de si necesita o no permisos de administrador para su secuencia de comandos de PowerShell (y realmente no debería solicitarlos si no lo hace), el archivo de proceso final debería verse como uno de los dos a continuación.

Sin acceso de administrador:

@ECHO OFF PowerShell.exe -NoProfile -ExecutionPoli cy Bypass -Command "& '% ~ dpn0.ps1'" PAUSE

Con acceso de administrador:

@ECHO OFF PowerShell.exe -NoProfile -Command "& {Start-Process PowerShell.exe -ArgumentList '-NoProfile - ExecutionPolicy Bypass -File "% ~ dpn0.ps1 " '-Verb RunAs} "PAUSE

Recuerde colocar el archivo por lotes en la misma carpeta que el script de PowerShell para el que desea usarlo, y asígnele el mismo nombre . Entonces, no importa en qué sistema se tomen esos archivos, podrá ejecutar su secuencia de comandos de PowerShell sin tener que perder el tiempo con ninguna de las configuraciones de seguridad del sistema. Sin duda, puede hacer esos cambios de forma manual todas las veces, pero esto le ahorra ese problema y no tendrá que preocuparse por revertir los cambios más adelante.

Referencias:

• Ejecución de scripts de PowerShell desde un archivo por lotes: Daniel Schroeder's Programming Blog
• Comprobación de permisos de administrador en PowerShell: ¡Hola, scripting guy! Blog

Cómo jugar juegos clásicos retro en Android

Gracias a los innumerables regalos que la ley de Moore sigue otorgando, introduciendo muchos de tus sistemas de juego retro favoritos en un teléfono que no es mucho más grande que medio paquete de naipes nunca ha sido más fácil de lo que es hoy. Muchas de las consolas más populares de nuestro pasado como NES, Sega Genesis y Playstation One se pueden disfrutar desde cualquier parte del mundo gracias a los emuladores móviles, pero es más fácil decirlo que hacerlo para comenzar a emularlo en Android.

(how-to)

Cerrar automáticamente (u ocultar) las aplicaciones inactivas en su Mac con Quitter

Se honesto: estás leyendo esto en lugar de trabajar, ¿verdad? Estoy agradecido, porque así es como me gano la vida, pero por tu bien deberías tratar de enfocarte. Es muy fácil abrir rápidamente Twitter o IM por "solo un minuto", especialmente cuando están abiertos en segundo plano. Quitter es una aplicación de Mac que puede ayudar.

(how-to)