tutorial - ¿Qué problema resolvió MS mediante la creación de PowerShell?

powershell tutorial

Question

Lo estoy preguntando porque PowerShell me confunde.

He intentado escribir algunas secuencias de comandos de implementación con PowerShell y el resultado no me ha entusiasmado. Tengo un compañero de trabajo que ama PowerShell y lo defiende en todo momento. Dice que el compañero de trabajo afirma que PowerShell nunca se escribió para ser un shell fuerte, sino que se escribió para:

a) Permitir que asome y pique en los ensamblados de .NET en la línea de comandos (¿por qué esta es una razón para que PowerShell exista?)

b) Alojarse en aplicaciones .NET para la automatización, similar a DCOP en KDE y cómo Gnome está utilizando CORBA.

c) ser tratado como "secuencia de comandos .NET" en lugar de como un shell real (relacionado con b).

Siempre he sentido que a Windows le faltaba una forma decente de eliminar las secuencias de comandos de automatización. cmd es demasiado simplista en muchos casos, y WSH es demasiado obtuso (aunque la combinación se puede usar con éxito, no soy fan). Cuando escuché por primera vez sobre PowerShell, sentí que Windows finalmente estaba obteniendo un caparazón decente que podría ayudar con la automatización de muchas tareas, pero las experiencias recientes, y mi compañero de trabajo, me dicen lo contrario.

Para que quede claro, no me molesta el hecho de que está basado en .NET, o que pasa objetos en lugar de texto (a pesar de mi fondo de Unix:]), y no estoy argumentando que PowerShell es inútil, pero por lo que puedo ver, no resuelve el problema que esperaba que resolviera muy bien. Tan pronto como salgas del mundo de .NET / Powershell, las cosas dejarán de ser agradables y acogedoras para ti.

Entonces, con todo eso fuera del camino, ¿qué problema resolvió MS al crear PowerShell, o es un hijo bastardo político como sospecho? He buscado en Google y no he encontrado nada que haya respondido lo suficiente para mí, pero cuantas más citas haya, mejor.

Answer 1

Como desarrollador, puedo decirle que ya no tengo muchos proyectos de ConsoleApplication42 en una carpeta.

Como desarrollador de una pequeña empresa donde prácticamente hago todo lo relacionado con TI (DBA, manipulo enrutadores, extraigo registros de detalles de llamadas desde el conmutador, superviso y grafico el ancho de banda para los clientes, etc.) puedo decirte que PowerShell llena un poco la brecha necesaria en Windows y el hecho de que está construida en .NET proporciona una ruta de actualización sin problemas cuando la conexión de PowerShell es demasiado lenta para manejar millones de iteraciones o se necesita una implementación más permanente y fuertemente tipada.

De todos modos, supongo que la pregunta es por qué te estás cambiando a PowerShell si no tienes una necesidad apremiante? Quiero decir que es bueno aprenderlo ahora ya que es básicamente la nueva interfaz de administración para todo lo relacionado con Microsoft. Pero si eso no te afecta, no te molestes si no crees que estás ganando algo.

EDITAR (En respuesta a los comentarios a continuación)

Parece que estás intentando usar la clase de proceso .NET para ejecutar un exe y redirigir su stdout para que la persona que llama pueda leerlo. Estoy de acuerdo en que es un dolor en .NET pero, afortunadamente, PowerShell hace todo esto por ti de forma sencilla. En cuanto a capturar el resultado y escribirlo en la pantalla, es bastante simple, aunque el comando no es muy conocido porque no se usa con tanta frecuencia. Aquí hay un ejemplo:

# I always find it easier to use aliases for external commands
Set-Alias csc C:/Windows/Microsoft.NET/Framework64/v3.5/csc.exe
# Create some source file
Set-Content test.cs @"
class Program {
static void Main() {
System.Console.WriteLine("Hello World");
}
}
"@
# Call CSC.EXE
# the output of csc.exe is written to results.txt and piped
# to the host (or select-string if you prefer)
csc test.cs | Tee-Object -file results.txt
# Check for errors
if ($LASTEXITCODE) {
# this is where community extensions would come in
# handy. powershell 2.0 also has a command to send
# mail but in 1.0 you can grab one from poshcode.org
}

Answer 2

En mi humilde opinión, la principal ventaja parece ser un corte y pegado razonable en la consola de comandos.

De lo contrario, uso ActivePerl de ActiveState para ActivePerl scripts en Windows. Es mucho más poderoso que cualquier script de shell de Windows, y la interfaz OLE expone toda la API de Windows de una manera fácil de usar.

Answer 3

PowerShell en realidad se construyó como varias cosas: una plataforma de automatización madura y extensible y un shell de administración moderno.

El primero se usa principalmente para las GUI de administración para Exchange y otros productos de servidor de los últimos tiempos. La GUI es solo una envoltura alrededor de PowerShell que hace la pesada carga detrás (algo así como los programas UNIX GUI vienen a ser, como un contenedor para un programa de línea de comandos).

Jeffrey Snover (inventor de PowerShell) explica un poco sobre cómo se creó PowerShell con qué objetivos y problemas debe resolver.

En mi opinión, PowerShell como shell está claramente pensado como un reemplazo para cmd (fácil de ver) y Windows Script Host (Windows Script Host no recibió mucha atención en los últimos años, a pesar de que tenía conceptos similares a .NET de nuevo en su día [una plataforma, varios idiomas con ActiveScripting], pero con .NET Microsoft básicamente lo dejó descansar y la resurrección probablemente no era una opción para ellos).

Unifica la mayoría de los aspectos de la administración de Windows en conceptos y métodos comunes que solo debe aprender una vez. Además, la potencia en PowerShell para mí radica en gran medida en que pasa alrededor de objetos que podrían explicar por qué te metes en problemas cuando sales del mundo de .NET / PowerShell donde solo obtienes un String[] de un comando. Pero para muchas cosas que llamarías un programa externo en cmd, hay un cmdlet que lo hará por ti.