El otro día estuve probando el
Windows PowerShell durante un rato para ver que aportaba y cuales eran las novedades. En especial, si iba a facilitar la administración de sistemas de Windows, o se iba a tener que recurrir a otras alternativas (Visual Basic Script) o lenguajes como
Python o
Perl
Cuando se ejecuta la primera vez, tienes la pinta de estar en un shell normal, con las tradicionales órdenes para moverse por el sistema de ficheros (y no sólo el sistema de ficheros, como veremos un poco más adelante), y ejecutar comandos externos. Hasta aquí no se diferencia en nada de cualquier shell (bash,cmd.exe, etc)
El shell
Las diferencias empiezan cuando profundizas en el shell. El shell de Microsoft no utiliza el habitual parse de cadenas, con órdenes internas (built-in) y comandos externos para realizar tareas interactivas o scripting. Lo que hace es aceptar y mostrar objetos .NET - está construido sobre el .NET 2.x -. ¿Y cómo se crean esos objetos?. Pues a través de lo que Microsoft denomina
cmdlet, que son funciones simples que están implementadas en el shell. La llamada a cualquiera de esas funciones nos devolverá un objeto .NET al cual podremos usar sus propiedades y funciones, combinarlos como entradas a otros objetos y hacer las operaciones que tenemos. Podemos además usar pipes de objetos para encadenarlos unos con otros.
Namespaces
Lo que más me llama la atención son los
namespace, espacios de nombres por lo cual podemos navegar como si fuera un sistema de ficheros tradicional. Desde luego, el primer
namespace que tenemos es el sistema de ficheros. Cada unidad de disco corresponde a un
namespace donde podemos usar las tradicionales órdenes ls, dir, cd, mkdir etc. Sin embargo, existe otra serie de espacios de nombres como las variables de entorno:
env:, los alias
alias:, los certificados
cert: o las claves de registro
hkcu: o
hklm:. Por ejemplo es se puede ver las variables de entorno con:
cd env:
ls
O navegar por el almacén de certificados de la máquina con:
cd cert:
ls
Esta es una de las posibilidades que más me ha llamado la atención del shell, esa posibilidad de interpretar todo como si fuera un sistema de ficheros y procesarlo como tal, en línea de Plan 9
cmd-let
Los comandos que crean objetos para poder manipular y obtener la información se denominan
cmd-let. Son funciones simples, con nombres descriptivos que Microsoft quiere que hagan tareas concretas - muy en la línea del diseño de utilidades Unix, con programas que hagan una sola tarea y que puedan encadenarse entre ellos para obtener el resultado buscado -. Este último modelo en Windows es poco viable, puesto que Windows siempre ha sido muy lento a la hora de crear procesos - modelo Unix tradicional con el uso de fork() - frente a la hora de crear hilos de ejecución dentro de un proceso - no sabría decir, supongo que el modelo derivado de Mach -
Por ejemplo get-date es un comando que devuelve la fecha mientras que get-command devuelve todos los cmdlet que tengamos en la sesión actual. Hacer notar que las utilidades que usamos para movernos por el sistema de ficheros (cd, dir, ...) realmente son alias a los cmdlet que ejecutan dichas funciones.
Posibilidades
Puesto que quieren basar parte de la administración del sistema sobre scripting - Windows siempre ha sido criticado con toda la razón por lo complicado de hacer scripting -, se ha añadido soporte para interactuar con wmi (y por tanto con toda la instrumentación de Windows), obtener información de los registros de eventos del sistemas, interactuar con el registro de Windows, los almacenes de certifados, y lo que la gente quiera implementar a través de sus funciones.
Estas han sido mis primeras impresiones del programa. Habrá que ver como compite contra el propio Visual Basic de Windows u otros lenguajes scripting que existen en la plataforma, y también el lugar que le reserva Microsoft para su uso, puesto que si ellos no le sacan jugo, es probable que todo se quede en buenas intenciones.