¿PowerShell está listo para reemplazar mi shell Cygwin en Windows? [cerrado]

384

Estoy debatiendo si debo aprender PowerShell, o simplemente seguir con los scripts Cygwin / Perl / Unix, etc.

El beneficio de PowerShell sería que los scripts podrían ser utilizados más fácilmente por los compañeros de equipo que no tienen Cygwin; Sin embargo, no sé si realmente estaría escribiendo tantos scripts de propósito general, o si la gente incluso los usaría.

Las secuencias de comandos de Unix son tan poderosas, ¿PowerShell se acerca lo suficiente como para justificar el cambio?

Estas son algunas de las cosas específicas (o equivalentes) que estaría buscando en PowerShell:

  • grep
  • ordenar
  • uniq
  • Perl (¿qué tan cerca está PowerShell de las capacidades de Perl?)
  • AWK
  • sed
  • archivo (el comando que proporciona información del archivo)
  • etc.
Andy White
fuente
77
No diría eso, estaba interesado en adquirir Powershell, encontré esta página y ahora sé las diferencias generales entre PS y las secuencias de comandos de shell a las que estoy acostumbrado.
Bender the Greatest
55
Esta publicación de repente surgió de las cenizas en un enlace de HN. Buen trabajo. Y malo para @Bobby por cerrar esto como no constructivo.
Sid
26
Si alguien no puede preguntar qué tan bien una herramienta replica las funciones de otra, entonces SO no puede responder las preguntas de comparación de herramientas. Esto está redactado cuidadosamente para evitar controversias, pero fue descuidado presumiblemente "controvertido" simplemente por parecer una pregunta de Unix vs Windows. Y obtuvo una respuesta objetiva y objetiva, con una visión fáctica adicional de cuán útil podría ser la creación de scripts de Unix en Windows.
chernevik
16
¿Por qué está cerrado de nuevo? Alguien edite el título para decir "PowerShell vs Unix Shells en la plataforma Windows" para evitar que los trolls lo traten como "Windows vs Unix", lo que no es así. Esta es una pregunta perfectamente constructiva: votó para reabrir.
x0n
3
La operación es mezclar shell con herramientas. PowerShell tiene su uso. Pero GNU es un proyecto para llevar productos UNIX a otros sistemas operativos, incluido Windows. Todo lo que aparece en la lista de operaciones tiene una implementación de GNU en Windows. Accesible desde GnuWin32 o sitios individuales. Windows BAT no es inútil, tiene redirección, canalización y condiciones.
MeaCulpa

Respuestas:

783

Las herramientas son solo herramientas.
Ayudan o no.
Necesitas ayuda o no la necesitas.

Si conoce Unix y esas herramientas hacen lo que necesita que hagan en Windows, entonces usted es un tipo feliz y no hay necesidad de aprender PowerShell (a menos que quiera explorar).

Mi intención original era incluir un conjunto de herramientas de Unix en Windows y terminar con esto (algunos de nosotros en el equipo tenemos profundos antecedentes de Unix y una buena dosis de respeto por esa comunidad).

Lo que encontré fue que esto realmente no ayudó mucho. La razón de esto es que AWK / grep / sed no funciona contra COM , WMI , ADSI , el Registro, el almacén de certificados, etc., etc.

En otras palabras, UNIX es un ecosistema completo autoajustado alrededor de archivos de texto. Como tal, las herramientas de procesamiento de texto son efectivamente herramientas de gestión. Windows es un ecosistema completamente diferente autoajustado en torno a API y objetos. Por eso inventamos PowerShell.

Lo que creo que encontrarás es que habrá muchas ocasiones en que el procesamiento de texto no te dará lo que quieres en Windows. En ese punto, querrás elegir PowerShell. NOTA: no es un acuerdo de todo o nada. Dentro de PowerShell, puede llamar a sus herramientas de Unix (y usar su proceso de texto o el procesamiento de texto de PowerShell). También puede llamar a PowerShell desde sus herramientas de Unix y obtener texto.

Una vez más, no hay religión aquí, nuestro enfoque es darle las herramientas que necesita para tener éxito. Es por eso que nos apasiona tanto la retroalimentación. Háganos saber dónde nos estamos cayendo en el trabajo o dónde no tiene una herramienta que necesita y la pondremos en la lista y lo buscaremos.

Honestamente, nos estamos cavando de un hoyo de 30 años, por lo que nos llevará un tiempo. Dicho esto, si elige la versión beta de Windows Server 2008 / R2 y / o las versiones beta de nuestros productos de servidor, creo que se sorprenderá de lo rápido que se llena ese vacío.

Con respecto al uso, hemos tenido más de 3.5 millones de descargas hasta la fecha. Eso no incluye a las personas que lo usan en Windows Server 2008, porque está incluido como un componente opcional y no necesita una descarga.

V2 se enviará en todas las versiones de Windows. Estará activado de forma predeterminada para todas las ediciones, excepto Server core, donde es un componente opcional. Poco después de que se envíe Windows 7 / Windows Server 2008 R2, haremos que V2 esté disponible en todas las plataformas, Windows XP y superior. En otras palabras, su inversión en aprendizaje será aplicable a una gran cantidad de máquinas / entornos.

Un ultimo comentario. Si / cuando comienzas a aprender PowerShell, creo que estarás bastante feliz. Gran parte del diseño está muy influenciado por nuestros fondos de Unix, por lo que, si bien somos bastante diferentes, lo recogerás muy rápidamente (después de que hayas insinuado que no es Unix :-)).

Sabemos que las personas tienen un presupuesto muy limitado para el aprendizaje, es por eso que somos muy duros con respecto a la coherencia. Aprenderás algo y luego lo usarás una y otra vez.

¡Experimentar! ¡Disfrutar! ¡Contratar!

Jeffrey Snover - MSFT
fuente
11
Gracias por tu respuesta. Creo que voy a seguir adelante y aprender PowerShell. Parece poderoso por lo que he visto hasta ahora, y podré escribir scripts más útiles con él en el trabajo.
Andy White
55
@ Jeffrey: ¿hay alguna posibilidad de una mejor terminal para Windows? Powershell es un poderoso lenguaje de scripting, pero el hecho de que se ejecute en cmd.exe lo hace mucho más conveniente en el modo interactivo
sumek
47
Esta pregunta "no constructiva" generó la mejor visión que he visto en todo el mantra "en Unix todo es un archivo", y por qué Windows es diferente. ¿Tal vez sería mejor servir StackOverflow para cerrar discusiones no constructivas ?
chernevik
12
@sumek: prueba ConEmu; Lo he estado usando durante algunas semanas y es bastante dulce: hanselman.com/blog/…
EZ Hart
44
Atención: a PowerShell no le gusta canalizar datos binarios. Así que tenga cuidado cuando llame a sus confiables herramientas Unix, simplemente no haga cosas como tar -c . | gzip > package.tar.gz directamente en PowerShell, o sufrirá. Ver brianreiter.org/2010/01/29/…
Interarticle
123

grep

Select-StringEl cmdlet y el -matchoperador trabajan con expresiones regulares. También puede utilizar directamente el soporte de expresiones regulares de .NET para una funcionalidad más avanzada.

ordenar

Sort-Objectes más poderoso (de lo que recuerdo * nix's sort). Permitir la ordenación multinivel en expresiones arbitrarias. Aquí el mantenimiento de PowerShell del tipo subyacente ayuda; por ejemplo, una DateTimepropiedad se ordenará como un DateTimesin tener que garantizar el formato en un formato ordenable.

uniq

Select-Object -Unique

Perl (¿qué tan cerca está PowerShell de las capacidades de Perl?)

En términos de la amplitud de las bibliotecas de soporte específicas de dominio de Perl: no está cerca (todavía).

Para la programación general, PowerShell es ciertamente más coherente y consistente, y más fácil de extender. La única brecha para la mezcla de texto es algo equivalente al ..operador de Perl .

AWK

Ha pasado bastante tiempo desde que usé AWK (debe ser> 18 años, ya que más tarde usé Perl), así que realmente no puedo comentar.

sed

[Véase más arriba]

archivo (el comando que proporciona información del archivo)

La fortaleza de PowerShell aquí no es tanto lo que puede hacer con los objetos del sistema de archivos (y obtiene información completa aquí, dirdevoluciones FileInfou FolderInfoobjetos según corresponda) es que ese es el modelo de proveedor completo.

Puede tratar el registro, el almacén de certificados, SQL Server, el caché RSS de Internet Explorer, etc., como un espacio de objetos navegable por los mismos cmdlets que el sistema de archivos.


PowerShell es definitivamente el camino a seguir en Windows. Microsoft lo ha convertido en parte de sus requisitos para futuros productos no domésticos. De ahí un rico soporte en Exchange, soporte en SQL Server. Esto solo se va a expandir.

Un ejemplo reciente de esto es el TFS PowerToys. Muchas operaciones de clientes TFS se realizan sin tener que iniciar tf.exe cada vez (lo que requiere una nueva conexión de servidor TFS, etc.) y es notablemente más fácil de procesar aún más los datos. Además de permitir un amplio acceso a toda la API del cliente TFS con mayor detalle que el expuesto en Team Explorer de TF.exe.

Ricardo
fuente
2
La cuestión es que el modelo de proveedor es interesante solo porque el sistema operativo no usa texto como su medio de configuración universal, por lo que NECESITA estos proveedores. Con UNIX, la mayoría de los idiomas tienen API para tocar PAM, hosts y paquetes, pero en última instancia, el texto siempre estará allí.
Daishiman
12
El texto no siempre es el mejor formato para todo (comience con bases de datos e imágenes ráster). Pero creo que podemos estar de acuerdo en no estar de acuerdo en lugar de guerras de formato abierto.
Richard
55
Powershell puede usar cualquier objeto en .NET Framework, ¿no coincide con las capacidades de dominio de Perl? Además, puedes escribir cmdlets en C #, etc., si quieres volver a usarlos
Chris S
Comparación punto por punto. Buena esa. Esta debería ser la respuesta aceptada. La fortaleza de PowerShell reside en sus fundamentos .NET y en la facilidad con que puede extender el sistema escribiendo nuevos Cmdlets o incluso llamando a bibliotecas de clases
Sau001
Un uso típico de sed (creo) sería:, sed 's/pattern/replacement/' fileque es aproximadamente gc file | %{$_ -replace 'pattern','replacement'}, y de manera similar para awk: awk 'BEGIN {} /pat1/ {action1} /pat2/ {action2} END {}' filees aproximadamente{BEGIN {}; switch -r -c -file file { 'pat1' {action1} 'pat2' {action2}}; END{};}
Nathan Chappell
56

Como alguien cuya carrera se centró en el desarrollo empresarial de Windows desde 1997 hasta 2010, la respuesta obvia sería PowerShell por todas las buenas razones dadas anteriormente (por ejemplo, es parte de la estrategia empresarial de Microsoft; se integra bien con Windows / COM / .NET; y el uso de objetos en lugar de archivos proporciona un modelo de codificación "más rico"). Por esa razón, había estado usando y promocionando PowerShell durante los últimos dos años más o menos, con la creencia expresa de que estaba siguiendo la "Palabra de Bill".

Sin embargo, como pragmático, ya no estoy seguro de que PowerShell sea una gran respuesta. Si bien es una excelente herramienta de Windows y proporciona un paso muy necesario para llenar el vacío histórico que es la línea de comandos de Windows, a medida que todos observamos el control de Microsoft sobre el deslizamiento de la informática de consumo, parece cada vez más probable que Microsoft tenga una batalla masiva por delante para mantener su sistema operativo como importante para la empresa del futuro.

De hecho, dado que encuentro que mi trabajo es cada vez más en entornos heterogéneos, me resulta mucho más útil usar scripts de Bash en este momento, ya que no solo funcionan en Linux, Solaris y Mac OS X, sino que también funcionan con el ayuda de Cygwin en Windows.

Entonces, si crees que el futuro del sistema operativo es mercantilizado en lugar de monopolizado, entonces parece tener sentido optar por una estrategia de herramienta de desarrollo ágil que se mantenga alejada de las herramientas propietarias cuando sea posible. Sin embargo, si ve que su futuro está dominado por todo lo que es Redmond, entonces elija PowerShell.

Ubiguchi
fuente
1
¿Los scripts de Unix funcionan perfectamente en Cygwin-Windows sin errores?
Pacerier
@Pacerier He estado usando Cygwin y MinGW durante 12 años, y tuve problemas sorprendentemente raros. Lo importante es que si algo no funciona, siempre es posible recurrir a las herramientas de Windows, o cualquier cosa: los procesos pueden iniciarse de la misma manera que cualquier otro shell los inicia.
Evgeni Sergeev
44
De acuerdo, su respuesta es de 2011. Hoy Powershell también se ejecuta en Linux. Y, mi opinión personal, bash es demasiado antiguo. La sintaxis es horrible y preferiría usar un lenguaje de script diferente. Hoy en día, con Python como estándar en la mayoría de las distribuciones de Linux, no veo ninguna razón para usar bash para los scripts. Te aconsejo que vuelvas a echar un vistazo a PowerShell, ya que ha sucedido mucho desde 2011.
itmuckel
33

He usado un poco de PowerShell para la automatización del script. Si bien es muy agradable que el entorno parezca haber sido pensado mucho más que los shells de Unix, en la práctica el uso de objetos en lugar de flujos de texto es mucho más complicado, y muchas de las instalaciones de Unix que se han desarrollado en los últimos 30 años. todavía faltan años.

Cygwin sigue siendo mi entorno de scripting preferido para los hosts de Windows. Ciertamente supera las alternativas en términos de hacer las cosas.

Daishiman
fuente
27
Usar objetos es un cambio de paradigma y lleva tiempo acostumbrarse. Pero evita el análisis completo en cada paso en el que intervienen datos estructurados (por ejemplo, no es necesario asegurarse de que los campos estén delimitados).
Richard
16
@Andy White @Daishiman, puedo entender dónde hay una curva de aprendizaje con PowerShell, pero los objetos de tubería pueden ser mucho más flexibles que el texto de tubería. @ Richard es correcto. :)
Steven Murawski
18
Los fabricantes de automóviles también tuvieron dificultades para discutir con más de 1000 años de caballos. No estoy tratando de ser impertinente. Solo señalar que el éxito pasado no elimina el beneficio potencial de la innovación.
EBGreen
12
@daishiman: el beneficio de los Objetos es que cuando quieres una propiedad, la pides, no tienes que analizar, adivinar, emitir. No entendí su punto sobre "qué sucede cuando los objetos no tienen métodos compatibles". ¿Podría decirlo de otra manera o dar un ejemplo del problema? Gracias.
Jeffrey Snover - MSFT
13
@Daishiman - Entiendo. En la práctica, la gente ha descubierto que esto no es un problema, sino una gran ventaja. Dicho esto, puedo ver que si usted fuera un analizador de textos experto, esta sería una nueva habilidad para aprender y al principio podría parecer innecesaria e incómoda. Nuevamente, lo que sea útil es la herramienta adecuada.
Jeffrey Snover - MSFT
15

Hay muchas respuestas geniales aquí, y aquí está mi opinión. PowerShell está listo si estás ... Ejemplos:

grep = " Select-String -Pattern "

sort = "Ordenar-Objeto"

uniq = " Get-Unique "

file = " Get-Item "

cat = " Obtener contenido "

Perl / AWK / Sed no son comandos, sino utilidades, por lo tanto, difíciles de comparar, pero puedes hacer casi todo en PowerShell.

Vic
fuente
2
¿Puedes creer los crípticos comandos de cuatro letras que nuestros antepasados ​​se vieron obligados a usar?
Evgeni Sergeev
44
@EvgeniSergeev Todo lo anterior están disponibles de forma predeterminada como sls, sort, gu, gi, gc, respectivamente. Nombres largos legibles que completan con tabulación y nombres cortos que se pueden escribir en un sistema. Eso es un progreso fácil de usar para ti.
TessellatingHeckler
Uno de los alias Get-Contentes cat, por lo que para ese no hay ninguna diferencia entre Cygwin / Unix y PowerShell. Desafortunadamente, en la mayoría de los casos, la documentación de Microsoft para los cmdlets carece de información sobre los alias, pero se genera una lista de todos los alias medianteGet-Alias una sesión de PowerShell. El alias de "Get-Unique" es "gu", por lo que es más corto que el de Cygwin / Unix.
Peter Mortensen
13

Hace poco comencé a incursionar en PowerShell con algún grado de seriedad. Aunque durante los últimos siete años he trabajado en un entorno casi exclusivamente basado en Windows, vengo de un fondo Unix y me encuentro constantemente tratando de "Unix-fy" mi experiencia de interacción en Windows. Es frustrante por decir lo menos.

Es justo comparar PowerShell con algo como Bash , tcsh o zsh ya que las utilidades como grep , sed , awk , find , etc. no son, estrictamente hablando, parte del shell; siempre serán, sin embargo, parte de cualquier entorno Unix. Dicho esto, un comando de PowerShell como Select-String tiene una función muy similar a grep y está incluido como un módulo central en PowerShell ... por lo que las líneas pueden ser un poco borrosas.

Creo que la clave es la cultura y el hecho de que los conjuntos de herramientas respectivos encarnarán sus respectivas culturas:

  • Unix es un basados en archivo , (en general, no Unicode) basado en texto cultura. Los archivos de configuración son casi exclusivamente archivos de texto . Windows, por otro lado, siempre ha estado mucho más estructurado con respecto a los formatos de configuración: las configuraciones generalmente se mantienen en bases de datos propietarias (por ejemplo, el registro de Windows) que requieren herramientas especializadas para su administración.
  • La interfaz administrativa de Unix (y, durante muchos años, desarrollo) ha sido tradicionalmente la línea de comando y el terminal virtual. Windows comenzó como una GUI y las funciones administrativas solo recientemente comenzaron a dejar de estar basadas exclusivamente en la GUI. Podemos esperar que la experiencia de Unix en la línea de comandos sea más rica y madura dada la importante ventaja que tiene en PowerShell, y mi experiencia coincide con esto. Sobre esto, en mi experiencia:

    • La experiencia administrativa de Unix está orientada a facilitar las cosas en una cantidad mínima de pulsaciones de teclas; Esto probablemente se deba a la situación histórica de tener que administrar un servidor a través de una conexión de acceso telefónico lenta de 9600 baudios. Ahora PowerShell tiene alias que ayudan mucho a sortear el estándar Verb-Noun bastante detallado , pero conocer esos alias es un poco molesto (¿alguien sabe algo mejor que alias | where {$_.ResolvedCommandName -eq "<command>"}:?).

      Un ejemplo de la rica forma en que se puede manipular la historia:

      iptablesLos comandos a menudo son largos y repetirlos con ligeras diferencias sería un dolor si no fuera por una de las muchas características de la manipulación del historial incorporadas en Bash , por lo que insertar una regla de iptables como la siguiente:

      iptables -I camera-1-internet -s 192.168.0.50 -m state --state NEW -j ACCEPT

      una segunda vez para otra cámara (" camera-2"), es solo un caso de emisión:

      !!:s/-1-/-2-/:s/50/51

      lo que significa "ejecutar el comando anterior, pero sustituir -1-con -2-y 50con 51.

    • La experiencia Unix está optimizada para mecanógrafos táctiles; uno puede hacer casi todo sin abandonar la posición de "hogar". Por ejemplo, en Bash , al usar las asociaciones de teclas de Emacs (sí, Bash también admite las vinculaciones vi ), el ciclo a través del historial se realiza usando Ctrl-Py Ctrl-Nmientras se mueve al inicio y al final de una línea se usa usando Ctrl-Ay Ctrl-Erespectivamente ... y definitivamente no termina ahí Pruebe incluso la navegación más simple en la consola PowerShell sin moverse de la posición de inicio y tendrá problemas.

    • Las cosas simples como la paginación versátil (al menos ) en Unix no parecen estar disponibles desde el primer momento en PowerShell, lo cual es un poco frustrante, y tampoco existe una experiencia de editor enriquecida. Por supuesto, uno siempre puede descargar herramientas de terceros que llenen esos vacíos, pero seguro que sería bueno si estas cosas estuvieran "allí" como si estuvieran en cualquier sabor de Unix.
  • La cultura de Windows, al menos en términos de API del sistema, está impulsada en gran medida por los marcos de soporte, a saber, COM y .NET , ambos altamente estructurados y basados ​​en objetos. Por otro lado, el acceso a las API de Unix ha sido tradicionalmente a través de una interfaz de archivo ( /devy /proc) o llamadas de biblioteca de estilo C (no orientadas a objetos). No sorprende entonces que las experiencias de secuencias de comandos coincidan con sus respectivos paradigmas del sistema operativo. PowerShell está estructurado por naturaleza (todo es un objeto) y basado en archivos Bash y sus amigos. La API estructurada que está a disposición de un programador de PowerShell es enorme (que coincide esencialmente con la inmensidad del conjunto existente de interfaces COM y .NET estándar).

En resumen, aunque las capacidades de secuencias de comandos de PowerShell son posiblemente más poderosas que Bash (especialmente si considera la disponibilidad de .NET BCL ), la experiencia interactiva es significativamente más débil, especialmente si lo hace desde un teclado completamente controlado. , perspectiva basada en consola (como lo son muchas cabezas Unix).

Eric Smith
fuente
Usted pregunta "alguien sabe de algo mejor que: alias | where {$ _. ResolvedCommandName -eq" <command> "}?". ¿Qué tal solo alias -Definition *property(o cualquier otro patrón)? Creo que el problema con su respuesta es que está combinando el shell y la consola: recuerde que tiene una opción de consolas con diferentes opciones de edición. Deliberadamente dejaron rota la edición de la consola de DOS para alentar a las personas a usar otras consolas como ISE.
Duncan
Por cierto, su !!ejemplo se puede escribir en Powershell como (h -c 1) -replace '-1-','-2-' -replace '50','51' | iexpero es más fácil subir la flecha y editar para un solo comando. Si quieres hacerlo a través de muchos comandos, creo que Powershell ganaría. Para repetir 10 comandos que terminan en el comando # 255 con sus ediciones: (h -c 10 -id 255) -replace '-1-','-2-' -replace '50','51' | iextambién el historial de Powershell le permite hacer cosas inauditas en shells de Linux; si se pregunta retrospectivamente cuánto tiempo tardó en ejecutarse un comando:h -id 20 | select { $_.EndExecutionTime - $_.StartExecutionTime }
Duncan
@Duncan Con respecto a su comentario sobre el shell y la consola, creo que esa es solo una diferencia fundamental entre Bash y PS; es decir: Bash espera ofrecer una cierta experiencia interactiva, mientras que PS "lo deja" a otra cosa. No tengo mucha experiencia con la consola ISE, pero por lo que recuerdo, tampoco tiene una experiencia interactiva tremendamente rica.
Eric Smith
@Duncan, sí, un buen punto sobre la capacidad de PS para cumplir con ingeniosos trucos de historia.
Eric Smith
@Duncan ... pero a pesar de su afirmación de que algunas cosas son desconocidas en los shells de Linux:fc -e "sed -i -e 's/-1-/-2-/g' -e 's/50/51/g'" 10 255
Eric Smith
8

No soy un usuario de PowerShell con mucha experiencia de ninguna manera, pero la pequeña parte de la que estuve expuesto me impresionó mucho. Puede encadenar los cmdlets integrados para hacer casi cualquier cosa que pueda hacer en un indicador de Unix, y hay algo adicional para hacer cosas como exportar a CSV, tablas HTML y para trabajos de administración de sistemas más detallados. .

Y si realmente necesita algo como sed , siempre hay UnixUtils o GnuWin32 , que puede integrar con PowerShell con bastante facilidad.

Como usuario de Unix desde hace mucho tiempo, sin embargo, tuve algunos problemas para acostumbrarme al esquema de nombres de comandos, y ciertamente me habría beneficiado más si supiera más .NET.

Así que, en esencia, digo que vale la pena aprenderlo si solo Windows no plantea un problema.

yalestar
fuente
1
Hay un proyecto de código abierto "Pash" que le permite ejecutar PowerShell en otras plataformas a través de Mono. tinyurl.com/6dyoso
John D. Cook
Whoa! Gracias por el consejo; No puedo esperar para probarlo
yalestar
6

Si te gustan los scripts de shell, ¡te encantará PowerShell!

Comience en una visita guiada de Microsoft Command Shell (Ars Technica).

Mella
fuente
8
Me encantan las secuencias de comandos de shell y tolero PowerShell. Sus comandos y sintaxis son atroces. Comandos y opciones horriblemente largos sin completar ningún comando útil. O si lo hay, no lo he encontrado. Demasiadas características agrupadas en comandos individuales que deberían separarse. Variable extraña y sintaxis de escape que solo un programador por lotes de DOS podría amar.
Zan Lynx
8
@Zan Lynx - Tienes razón sobre no haber encontrado cosas. Todos los comandos tienen alias, y muchos de ellos coinciden con los comandos de DOS y UNIX (ps, dir, rm, ls, kill, history, man, cat, clear, etc.) Los nombres son largos para que tengan un nombre significativo. Excelente para scripts: ayuda cuando una nueva persona tiene que usarlo y mantenerlo. Hay expansión de tabulaciones para cmdlets, funciones, variables, ruta, parámetros, etc. Gran parte de la sintaxis proviene de shells de Unix y ¿de qué sintaxis de escape está hablando? `` no se usa para escapar ya que es el separador de ruta en Windows.
manojlds
3
@Zan Lynx: sus argumentos no son válidos. Para dejar de interpretar variables, use '(comillas simples). Para lo de las comillas dobles, lo mismo, use write-output 'this is a "test"'. La pregunta que está señalando es para Regex y el escape para regex es válido en todas partes. Powershell también tiene cadenas Here-Strings / verbatim. ¡Incluso Java no tiene estos! Intenta escapar de la expresión regular en Java. Y a veces no usas literalpath. Lo usas cuando lo necesitas. LiteralPath trata los caracteres comodín textualmente y no los expande. Lo usas cuando tus archivos lo tienen. Te da más opciones.
manojlds
3
@manojlds: en comparación con bash shell, Powershell está lleno de inconsistencias que no tienen sentido y son confusas. En bash, usa el mismo carácter de escape en todas partes y las rutas de archivo se escapan igual que las cadenas. No necesita un parámetro especial para ello. Si expande una variable que tiene caracteres especiales, la pone entre comillas dobles y el contenido es seguro, no es necesario llamar a una función para volver a escapar.
Zan Lynx
55
@Zan Lynx: no hay inconsistencias. Incluso write-output "this is a `"test`""funciona. Solo use en `lugar de `\`. regex :: escape existe para ayudarte a que no te pierdas las cosas de escape. No es necesario usarlo. Está pensando que las opciones adicionales que existen para ayudarlo y evitar errores son inconsistencias.
manojlds
6

Como mis experimentos recientes me llevaron a profundizar en las llamadas de PowerShell y .NET, debo decir que PowerShell puede reemplazar a Cygwin y Unix shell.

No estoy seguro acerca de Perl, pero dado que PowerShell y Perl están completos en Turing como lenguajes de programación, le doy esto como un sí para reemplazar Perl también.

Una cosa que PowerShell tiene sobre Cygwin y Bash ordinario bajo * nix, es su capacidad de realizar llamadas DLL de espacio aislado, manipulando el sistema operativo a través de llamadas API directas, métodos WMI e incluso objetos COM. ¿Qué le parece iniciar Internet Explorer a través del código y luego hacer lo que quiera con el documento que se muestra, emulando efectivamente un back-end para un servidor web?

¿Qué tal reunir datos de servidores SQL y otros proveedores de datos, analizarlos y exportarlos como CSV, mensajes de correo, texto y en realidad cualquier tipo de formato de archivo existente y no existente? (Con las habilidades adecuadas para crear un archivo válido a partir de los datos recibidos, por supuesto, pero CSV están disponibles).

Y hay una seguridad adicional disponible a través de cmdlets y scripts firmados, políticas de grupo y políticas de ejecución que ayudan a evitar que se ejecute código malicioso en su sistema, incluso si los ejecuta como administrador.

Sobre qué comandos se implementan: la respuesta de Richard los enumera y la capacidad de PowerShell de emular su funcionalidad ya.

Acerca de si PowerShell es fuerte para justificar el cambio, esto es más una cuestión de preferencia personal, aunque a medida que más y más servicios de Windows proporcionan cmdlets de PowerShell para controlarlos, no usar PowerShell con estos servicios presentes se considera un obstáculo. (El servidor Hyper-V es el principal servicio de este tipo, ¡y también proporciona la capacidad de hacer más con los cmdlets de PowerShell que con la GUI!)

Probablemente esta respuesta llegue cinco años tarde, pero aún así, si alguien realiza tareas administrativas o secuencias de comandos generales de varias cosas en Windows, definitivamente debería intentar aprovechar PowerShell para sus propósitos.

Vesper
fuente
6

Cuando compare PowerShell con la combinación Cygwin / Perl / Shell, tenga en cuenta que PowerShell solo representa la parte "Shell" de esa combinación.

Sin embargo, puede invocar cualquier comando desde PowerShell tal como lo hace desde cmd.exe o Cygwin. No , no volver a implementar las funciones especificadas, y ciertamente no es comparable a la de Perl.

Es "solo" un shell, pero facilita la programación al proporcionar una interfaz cómoda para el universo .NET.

También tenga en cuenta que PowerShell requiere Windows XP, Windows Server 2003 o superior, lo que puede suponer un problema dependiendo de su infraestructura de TI.

Actualizar:

No tenía idea de qué tipo de debate filosófico provocaría mi respuesta.

Publiqué mi respuesta en el contexto de la pregunta: Compare PowerShell con Cygwin y Perl y Bash.

PowerShell es un shell, ya que no hace una diferencia sintáctica entre los comandos integrados, los comandos, las funciones del usuario y los comandos externos (.exe, .bat, .cmd). Solo invocar métodos .NET difiere al agregar un espacio de nombres o un objeto en la llamada.

Su programabilidad se deriva del marco .NET, no de nada específico del "lenguaje" de PowerShell.

Diría que creo que PowerShell es un "lenguaje de script" tan pronto como Bugzilla o MediaWiki se implementan como scripts de PowerShell que se ejecutan en un servidor web;)

Hasta entonces, disfruta las comparaciones .

devio
fuente
Sí, supongo que cuando estoy hablando del "shell" de Unix también me refiero a todas las utilidades normales que vienen con Unix, como grep, awk, etc. Me pregunto si PowerShell ofrece utilidades similares fuera de -la caja.
Andy White
3
Powershell no es "solo un caparazón". Es un lenguaje de script. Me pregunto de qué manera no es comparable a Perl. Admito que no es tan maduro, pero más allá de eso no veo la disparidad.
EBGreen
@EBGreen, ¿Qué quieres decir exactamente con este comentario? Estoy de acuerdo en que cualquier lenguaje de shell o scripting es intrínsecamente similar, pero me preguntaba más sobre las capacidades específicas de PowerShell vs. bash / perl / otros shells de Unix / lenguajes de scripting.
Andy White
2
Powershell tiene una increíble variedad de funciones. Es - Un shell interactivo y composable - Un rico lenguaje de scripting interactivo - Un lenguaje de programación Tiene un rico conjunto de funciones de utilidad OO y tesxt (es decir, equivalentes a grep / awk / etc) también.
Jeffrey Snover - MSFT
1
@Andy: entendí que Devio decía que PowerShell no es tan poderoso como Perl. No creo que eso sea cierto y me preguntaba por qué pensaba que era así.
EBGreen
4

Los cmdlets en PowerShell son muy agradables y funcionan de manera confiable. Su orientación a objetos me atrae mucho ya que soy un desarrollador de Java / C #, pero no es en absoluto un conjunto completo. Dado que está orientado a objetos, se perdió una gran parte de la madurez del flujo de texto del conjunto de herramientas POSIX ( awky sedpor nombrar algunos).

¡La mejor respuesta que he encontrado al dilema de amar las técnicas OO y amar la madurez en las herramientas POSIX es usar ambas! Un gran aspecto de PowerShell es que hace un excelente trabajo canalizando objetos a flujos estándar. PowerShell utiliza de forma predeterminada una tubería de objeto para transportar sus objetos. Estas no son las transmisiones estándar (salida estándar, error estándar y entrada estándar). Cuando PowerShell necesita pasar la salida a un proceso estándar que no tiene una canalización de objetos, primero convierte los objetos en una secuencia de texto. Como lo hace tan bien, PowerShell es un excelente lugar para alojar herramientas POSIX.

El mejor conjunto de herramientas POSIX es GnuWin32 . La instalación demora más de 5 segundos, pero vale la pena y, por lo que puedo decir, no modifica su sistema (registro, c:\windows\*carpetas, etc.), excepto copiar archivos a los directorios que especifique. Esto es muy bueno porque si coloca las herramientas en un directorio compartido, muchas personas pueden acceder a ellas simultáneamente.

Instrucciones de instalación de GnuWin32

Descargue y ejecute el exe (es del sitio de SourceForge ) apuntándolo a un directorio adecuado (lo usaré C:\bin). Creará un GetGnuWin32directorio allí en el que ejecutará download.bat, luego install.bat(sin parámetros), después de lo cual, habrá un C:\bin\GetGnuWin32\gnuwin32\bindirectorio que es la carpeta más útil que haya existido en una máquina con Windows. Agregue ese directorio a su ruta y estará listo para comenzar.

Expiación limitada
fuente
4

TL; DR: no odio Windows o PowerShell. Simplemente no puedo hacer nada en Windows o en PowerShell.


Personalmente, todavía encuentro PowerShell decepcionante en el mejor de los casos.

  • la finalización de la pestaña de las rutas de directorio no se compone, lo que requiere que el usuario ingrese un separador de ruta después de cada finalización de nombre.
  • Todavía siento que Windows ni siquiera tiene el concepto de una ruta o de qué es una ruta, sin un indicador de inicio de usuario accesible por ~/debajo de algunos@environment://somejibberish/%user_home%
  • NTFS sigue siendo un desastre y aparentemente siempre lo será. Buena suerte navegando.

  • interfaz cmd-esque, El dinosaurio cmd.exe todavía es visible en PowerShell, EditarMark sigue siendo la única forma de copiar información, y solo se copia en forma de bloques rectangulares de espacio terminal visible. y EditarMark sigue siendo la única forma de pegar cadenas en el terminal.

  • Pintarlo de azul no lo hace más atractivo. Sin embargo, no me importa que los desarrolladores de Microsoft prueben el color.

  • Windows siempre se abre en la esquina superior izquierda de la pantalla. Para alguien que usa barras de tareas verticales, esto es increíblemente molesto, especialmente teniendo en cuenta que la barra de tareas de Windows cubrirá la única esquina de la ventana que da acceso a la funcionalidad de copiar / pegar.

No puedo hablar mucho sobre la base de las herramientas que incluye Windows. Dado que existe un conjunto completo de herramientas de CLI de código abierto y de licencia libre, y PowerShell se envía con, que yo sepa, ninguna de ellas es una decepción total.

  • PowerShell wgetlleva argumentos aparentemente incomparables a GNU wget. Gracias, un rayo de esperanza portátilmente inútil.
  • PowerShell POSIX no es compatible con Bash, particularmente el &&operador no se maneja, lo que hace que el comando condicional más simple no sea una cosa.

No conozco hombre; Le di una oportunidad, realmente lo hice; Todavía trato de intentarlo con la esperanza de que la próxima vez que lo abra sea menos inútil. No puedo hacer nada en PowerShell, y apenas puedo hacer cosas con un proyecto real para llevar herramientas GNU a Windows.

MySysGit me da el mensaje dinosaurio cmd.exe con un par de herramientas GNU, y todavía es muy decepcionante, pero al final la ruta funciona. Y el comando Git se ejecutará en Git Bash.

Mintty para MySysGit ofrece la interfaz Cygwin sobre el entorno de mysysgit, haciendo que copiar y pegar sea algo (seleccione copiar (mouse), Shift+ Inspara pegar, qué moderno ...). Sin embargo, cosas como git pushestán rotas en Mintty.

No me refiero a despotricar, pero aún veo grandes problemas con la usabilidad de la línea de comandos en Windows incluso con herramientas como Cygwin.


PD: el hecho de que se pueda hacer algo en PowerShell no lo hace utilizable . La usabilidad es más profunda que la habilidad y es en lo que tiendo a enfocarme cuando trato de usar un producto como consumidor.

ThorSummoner
fuente
¿Activar el modo QuickEdit? Seleccione y presione enter para copiar, ctrl-v para pegar, no más Editar-> Marcar o Editar-> Pegar. Mientras esté en las preferencias, configure la posición de la ventana y desmarque "dejar ventana de posición del sistema". La finalización de tabulación no es solo completar rutas del sistema de archivos, también está completando nombres de variables, nombres de comandos, propiedades de objetos, puede estar a punto de escribir .o [acceder a una propiedad o índice, por lo que no puede simplemente agregar un separador de ruta al final. ¿Qué wget de PowerShell exactamente? ¿Qué POSIX de PowerShell? No está tratando de llevar herramientas gnu a Windows, o ser compatible con bash por cierto.
TessellatingHeckler
Sí, sé que no está tratando de ser bash. Me abstuve de decirlo en la publicación original. Diría qué w obtener binario, pero no hay un comando "qué" en power shell :( no recuerdo dónde comprar leí poder Shell se suponía que era compatible con POSIX
ThorSummoner
55
re: "no cuales" -> (get-command wg*.exe).Path. Re: finalización de bash y readline -> leeholmes.com/blog/2012/09/13/… que lleva a github.com/lzybkr/PSReadLine
TessellatingHeckler
2

No he visto que el PowerShell haya despegado realmente, al menos no todavía. Por lo tanto, puede que no valga la pena aprenderlo a menos que otros miembros de su equipo ya lo sepan.

Para su situación, podría estar mejor con un lenguaje de secuencias de comandos que otros podrían respaldar, Perl como mencionó u otros como Ruby o Python.

Creo que mucho depende de lo que necesites hacer. Personalmente, he estado usando Python para mis propios scripts personales, pero sé que cuando empiece a escribir algo que nunca podré transmitir, así que trato de no hacer nada demasiado revolucionario.

Greg
fuente
2

¿Por qué no usar ambos? Llame a los scripts de PowerShell en Cygwin como cualquier otro script interpretado como Perl, etc.

Hago esto lo suficiente como para escribir https://bitbucket.org/jbianchi/powershell para un contenedor Bash para llamar a powershell.exe en Cygwin. Se puede usar como shebang como la primera línea de un script .ps1 powershell.exe (ya que PowerShell también usa "#" como comentario). Ver https://bitbucket.org/jbianchi/powershell/wiki/Home para ver ejemplos

johnnyB
fuente
1

En un par de líneas, Cygwin y PowerShell son herramientas diferentes, sin embargo, si tiene instalado Cygwin, puede ejecutar los ejecutables de Cygwin dentro de una sesión de PowerShell. Me he acostumbrado tanto a PowerShell que ahora ya no uso grep, sort, awk, etc. Hay alternativas integradas en PowerShell, y si no, puede encontrar un cmdlet.

La herramienta principal que utilizo es ssh.exe, pero dentro de una sesión de PowerShell.

Funciona muy bien

yaxzone
fuente
0

Encontré que la programación de PowerShell no valía la pena.

Tengo varios años de experiencia con las secuencias de comandos de shell en Unix, pero me resultó enormemente difícil hacer casi cualquier cosa con PowerShell.

Parece que muchas funciones requieren que interrogue la interfaz de administración de Windows y emita comandos similares a SQL para obtener la información que necesita.

Por ejemplo, quería escribir un script para eliminar todos los archivos con un sufijo específico de un árbol de directorios. Bajo Unix, esto sería un simple ...

find . -name \*.xyz -exec rm {} \;

Después de un par de horas dicking alrededor con Scripting.FileSystemObjecty WScript.Shelly la emisión de "SELECT * FROM Win32_ShortcutFile donde unidad = '" & Drive & ' 'Y Path ='' & SearchFolder & "'", finalmente me di por vencido y conformé del Explorador de Windows Búsqueda de mando y solo hazlo manualmente. Probablemente haya alguna forma de hacer lo que quería, pero no vi nada obvio y todos los ejemplos en el sitio de MSDN eran tan triviales que no valían nada.

EDITAR Heh, por supuesto, tan pronto como escribí esto, busqué un poco más y encontré lo que me faltaba: la -recurseopción del comando remove-item es defectuosa (se revela si la usa get-help remove-item -detailed).

Había estado intentando "remove-item -filter '* .xyz' -recurse" y no funcionaba, así que me di por vencido.

Resulta que necesitas usar get-childitem -filter '*.xyz' -recurse | remove-item

TMN
fuente
16
Creo que estás confundiendo Windows Scripting Host (WSH) con PowerShell. Son totalmente diferentes
Erik Funkenbusch
3
Como ejemplo, si desea eliminar todos los archivos que terminan en .TMN, puede emitir este comando get-childitem c: \ -include * .TMN -recurse | foreach ($ _) {remove-item $ _. fullname}
Erik Funkenbusch
@Mystere: Intenté esto, y no pareció funcionar. Después de pensar un poco, parece que * .tmn es lo que necesita (en lugar de solo .tmn)
redtuna
55
No podría estar más en desacuerdo respetuosamente, y de ninguna manera soy un chico de Windows. Encuentro que PS es mucho más fácil de escribir que bash. PS es más consistente. Con Bash, cualquier utilidad de consola que invoques tiene su propia sintaxis y un comportamiento único, y la sintaxis bash en sí es bastante críptica. PS es mucho más robusto con características de lenguaje como funciones anónimas (bloques de script), validación de parámetros, funciones avanzadas, etc. Además de conceptos de módulos para portabilidad y muchas otras características. Sin embargo, principalmente, la razón más importante es lo que siempre escuchas sobre PS, los objetos triunfan sobre el texto. Sin embargo, Bash es aún más rápido.
user2233949
0

PowerShell es muy potente, más potente que las funciones integradas estándar de los shells de Unix (pero solo porque incluye gran parte de la funcionalidad que generalmente se aplica a los subprogramas). Además, tenga en cuenta que se puede escribir applets en cualquier lenguaje .NET, incluyendo IronPython , IronRuby , PerlNET, etc .. o simplemente puede llamar a los comandos de PowerShell de Cygwin, ignorando toda la funcionalidad adicional y funcionará de manera similar a Bash, KornShell , o lo que sea...

Erik Funkenbusch
fuente
Creo que puede estar perdiendo los objetivos de diseño de los shells de Unix. Sin tocar PowerShell (me gustaría aprender más yo mismo), pero necesita comprender las herramientas de Unix para hacer una declaración como esa.
Jé Queue
2
@Xepoch - No, creo que te estás perdiendo los objetivos de diseño de PowerShell. PowerShell puede hacer todo lo que los shells de Unix pueden hacer de la misma manera que lo hacen. Sin embargo, la potencia real se produce cuando utiliza el sistema de tuberías de objetos de PS en lugar de simplemente analizar la salida de texto. Entonces, PowerShell puede hacer exactamente lo que bash o korn pueden hacer, pero no pueden hacer lo que PowerShell puede hacer.
Erik Funkenbusch
3
Simplemente no conozco PowerShell lo suficiente como para hacerle una crítica al respecto, pero como sabe claramente, los objetivos de los shells Unix no son necesariamente un reemplazo completo de las herramientas externas, sino las estructuras de control a su alrededor. Nuevamente, en este momento no puedo comparar ni contrastar, pero elevar PowerShell porque tiene más funciones incorporadas no es necesariamente una bendición para los shells de Unix.
Jé Queue
@Xepoch: el punto es que puedes elegir la forma en que quieres hacerlo. Puede usar toda la bondad del shell incorporado, o puede ignorarlo y hacerlo como lo hace Unix. Es tu elección. Y la elección es buena, ¿verdad?
Erik Funkenbusch