¿Cuáles fueron las razones por las que Windows nunca tuvo un shell decente? [cerrado]

Estaba leyendo un tema sobre SO: ¿Por qué los lenguajes de secuencias de comandos (por ejemplo ...) no son adecuados como lenguajes de shell? . Especialmente me gustó la respuesta de Jörg W Mittag , de la que aprendí cosas interesantes Windows PowerShell. Entonces, después de más de 20 años, Windows finalmente tiene un shell bien diseñado (Windows 1.0 - 1985, lanzamiento estable de PowerShell - 2009). Por otro lado, los sistemas Unix tienen varios shells desde 1978 Bourne Shell. He leído algunos artículos sobre entrevistas de trabajo de MS y tengo la impresión de una compañía muy "geek". Me pregunto por qué no necesitaban herramientas de línea de comandos en comparación con las personas de Unix que hacen todo su trabajo con esas herramientas.

La misma razón que el iPod, el iPhone (cualquier teléfono) y el iPad no: la línea de comando no es el canal principal de interacción del usuario con la computadora en Windows. Está en UNIX o GNU / Linux, por eso son más maduros. El mismo argumento por el que los escritorios de la GUI de Linux fueron basura durante tanto tiempo en comparación con Windows (Mac OS hace trampas desde que obtuvieron la línea de comandos de Unix de forma gratuita).

Tal vez estoy simplificando demasiado, pero lo considero una cuestión cultural:

1. En la cultura de Microsoft, los desarrolladores se centran en escribir programas para sus usuarios . Todos los programas están basados ​​en GUI.
2. En la cultura Unix, los desarrolladores se centran en escribir programas para otros desarrolladores . Los programas son pequeños y se centran en hacer bien algo específico.

Tenga en cuenta que no hay razón para que Microsoft pueda ser el único en escribir un shell para Windows. Los tipos que escriben bash son diferentes de los que escriben * nix kernels. Ni siquiera necesita privilegios de root. He compilado mis propios shells para usar cuando no me gustó el que instaló el administrador del sistema. Si hubiera una verdadera demanda de un mejor shell de Windows, alguien habría escrito uno.

Porque nunca ha habido suficiente llamada para uno, supongo.

Windows Scripting Host se ha instalado como estándar desde Windows 98 (supongo que existía antes); VBScript fue muy capaz; o podría escribir fácilmente una herramienta de línea de comandos, que tenía acceso a toda la API de Windows.

Powershell, en pocas palabras, es solo otro paso en la misma dirección. COM ya no es popular, por lo que WSH se ha convertido en un proceso de aprendizaje. Pero .NET es la gran cosa actual en el mundo de Windows y aprender Powershell desde un fondo .NET es relativamente fácil.

Sin embargo, creo que un lugar en el que Powershell salió mal es tratar de atraer a la multitud * nix, con todos sus alias que hacen que parezca Bash cuando claramente no lo es.

Además de los interruptores de la línea de comandos, la tubería es muy diferente en Powershell y es realmente lo primero que debes aprender cuando lo recoges.

Y honestamente, se parece mucho más a un lenguaje de script, a la Perl, que a un shell, a la Bash. Hay algunos problemas serios si intentas usarlo como tu shell principal.

Por ejemplo, intente hacer un volcado SVN simple desde Powershell. No maneja muy bien los datos binarios en stdout. Por otro lado, manipular un registro SVN es un sueño absoluto, gracias a su tipo xml incorporado.

Porque hay poca necesidad y mucho dolor en el desarrollo de un segundo conjunto de herramientas paralelas de Windows.

Los shells se hacen poderosos a través del número y el poder de los programas de ayuda en un sistema GNU, como sed, find, xargs et al. Reimplementar estas herramientas es mucho trabajo, y solo construir una capa de cumplimiento POSIX sobre Windows ha resultado mucho más fácil. Cygwin es una capa de cumplimiento POSIX y satisface la mayoría de las necesidades que los usuarios de shell tienen cuando se ven obligados a usar Windows.

Personalmente, supongo que la comunidad de desarrolladores que no está dispuesta a subirse al tren de POSIX y Linux y que aún se dedica lo suficiente a la programación de shell es tan pequeña que llevó 20 años desarrollar un shell estable.

Esta es una de esas preguntas que, ignorando las teorías de la conspiración, probablemente no tiene una sola respuesta y es el tipo de cosas sobre las que los historiadores podrían discutir para siempre sin encontrar una respuesta definitiva.

Mi impresión es que el poder del proyectil no es inmediatamente obvio. Comencé a programar en Windows 3.1 y había muy poco uso del shell. Todo se hizo a través del IDE de Visual C ++, y nunca miré los archivos MAKE y los archivos por lotes de DOS eran tan limitados que rara vez intenté usar un archivo por lotes para automatizar algo más complicado que una copia de seguridad básica. Ninguno de los libros de programación enfocados en Windows (tengo buenos recuerdos de Petzold ) que estaba leyendo en ese momento discutió el uso del shell de Windows para nada. No fue hasta que comencé a usar y programar Linux que entendí lo útil que podría ser un shell poderoso. Recuerdo que cuando salió Windows fue muy emocionante porque no tenías que usar viejoscommand.comnunca más. Finalmente tuvimos una interfaz bonita con más de una fuente y múltiples programas ejecutándose al mismo tiempo sin la necesidad de un TSR ...

Creo que la mayoría de los programadores que comienzan en Windows simplemente no tienen experiencia con un shell poderoso y, por lo tanto, no sienten la necesidad apremiante de implementar uno para Windows. Los programadores que trabajan en Linux y aprecian el shell, prefieren trabajar en Linux y, por lo tanto, no se sienten inclinados a pasar el tiempo trabajando en un entorno en el que no se sienten tan cómodos para implementar uno para Windows, especialmente teniendo en cuenta (como se ha señalado en otra pregunta) la necesidad de implementar también todas las herramientas de CLI que se necesitan junto con el propio shell.

La creciente popularidad de Linux es, probablemente, la razón principal por la que Microsoft finalmente puso un shell apropiado. A medida que más y más personas se dieron cuenta de lo que es útil para un shell, se hizo cada vez más claro que a Windows le faltaba una herramienta importante.

Si considera que los shells de Unix son "decentes", ha habido al menos un shell para Windows que ha sido "decente" durante décadas. El shell Hamilton C está razonablemente cerca del shell Unix C (aunque tenga en cuenta que el shell C nunca ha tenido una penetración de mercado particularmente grande en Unix). Muchas personas también han usado varios shells de JPSoft (4DOS, 4NT, ahora llamado Take Command) durante bastante tiempo, como probablemente se puede adivinar por el nombre, 4DOS se remonta a los días de MS-DOS.

Si insiste en un shell distribuido por Microsoft, hace aproximadamente 15 años, el kit de recursos de Windows NT solía incluir un puerto NT del PD Korn shell ¹ , junto con un buen número de utilidades Unix-ish. Probablemente no incluía lo suficiente para ejecutar una gran cantidad de scripts de shell sin modificación, pero fue suficiente para manejar una buena cantidad de uso, especialmente un poco de trabajo interactivo.

¹ Con toda honestidad, no sé si era un puerto de ese caparazón exacto, o simplemente algo bastante similar: lo usé lo suficiente como para verificar que era tan molesto como recordaba que eran los caparazones de Unix, y lo dejé así. .

Windows tiene características de diseño que no se prestan a las secuencias de comandos. Esto es el resultado de hacer que la interfaz gráfica sea el modo principal de operación. Muchas herramientas no tienen interfaces de línea de comandos funcionales. Sin una interfaz de línea de comandos decente, es muy difícil generar un buen shell.

A menudo, las cosas que necesitan ser escritas en Windows requieren clics del mouse y pulsaciones de teclas para simularse en varias ubicaciones en una ventana de aplicaciones. Los guiones resultantes pueden ser bastante frágiles. Describir dónde escribir en un lenguaje de comandos no es un ejercicio trivial, ya que la geometría relevante no está disponible fácilmente.

Windows tampoco tenía un mecanismo de tubería funcional en las primeras versiones. Como se describió, el primer proceso se ejecutará y su salida se guardará en un archivo temporal. Ese archivo se usaría como entrada para el siguiente comando. Esto podría ser intensivo en disco y fallaría si no hubiera suficiente espacio temporal disponible. Las tuberías Unix pasan los datos en la memoria y programan los procesos de una manera que minimiza los retrasos.

Cuando se lanzó, en 1993, Windows NT fue un movimiento de MS hacia el espacio que anteriormente ocupaban los servidores Unix y en ese momento se hizo un gran negocio sobre la compatibilidad y portabilidad POSIX. Pero no hizo el trabajo: en cambio, sus usuarios eran más gente de escritorio que usaba un mejor hardware (estos eran los días en que un 486dx 50MHz con 32MB de RAM estaba cerca del extremo superior) y querían un mejor sistema operativo. Pero no estaban interesados ​​en las conchas, por lo que todo se deslizó. En el momento de Windows Server 2000, que fue un segundo intento serio de descifrar este mercado, creo que MS se había dado cuenta de que eran débiles en el lado de la shell, ya que los administradores adoran los scripts de shell, pero incluso entonces les tomó algo de tiempo rascarse la picazón.