¿Qué problema solucionó MS al crear PowerShell?

Question

Pregunto 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. Dichas afirmaciones de compañeros de trabajo de PowerShell nunca se escribieron para ser un shell fuerte, sino que se escribieron en:

a) Permiten echar un vistazo y examinar asambleas .NET en la línea de comandos (¿por qué es motivo de PowerShell? ¿existir?)

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

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

Siempre he sentido que a Windows le faltaba una forma decente de eliminar los scripts 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 ser 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.

Así que con todo eso fuera del camino, ¿qué problema resolvió MS al crear PowerShell, o es un niño 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

PowerShell se construyó en realidad 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) elaborates a little sobre cómo se creó PowerShell con qué objetivos y problemas debe resolver.

En mi opinión, PowerShell como shell está 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, aunque tenía conceptos similares a .NET en su día [una plataforma, varios idiomas con ActiveScripting], pero con .NET Microsoft básicamente lo puso a 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í proviene en gran medida de 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[] desde un comando. Pero para muchas cosas que llamarías un programa externo en cmd, hay un cmdlet que lo hará por ti.

Answer 2

Como desarrollador, puedo decirle que ya no tengo un montón de proyectos de ConsoleApplication42 en una carpeta.

Como desarrollador en una pequeña empresa donde prácticamente hago todo IT (DBA, manipulo enrutadores, extraigo registros de detalles de llamadas desde el conmutador, superviso y grafico ancho de banda para clientes, etc ...) Puedo decirte que PowerShell cubre un vacío tan necesario en Windows y el hecho de que está desarrollado 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é cambias 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 más abajo)

Parece que usted está tratando de utilizar la clase Process de .NET para poner en marcha un exe y redirigir la salida estándar está para que pueda ser leído por la persona que llama. 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 3

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

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