Quelles sont les raisons pour lesquelles Windows n'a jamais eu un shell décent? [fermé]

Je lisais un sujet sur SO: Pourquoi les langages de script (par exemple ...) ne conviennent-ils pas comme langages shell? . J'ai particulièrement aimé la réponse de Jörg W Mittag , dont j'ai appris des choses intéressantes Windows PowerShell. Ainsi, après plus de 20 ans, Windows a enfin un shell bien conçu (Windows 1.0 - 1985, version stable PowerShell - 2009). D'un autre côté, les systèmes Unix ont un tas de coquilles diverses depuis 1978 Bourne Shell. J'ai lu quelques articles sur les entretiens d'embauche chez MS et j'ai une impression d'entreprise très "geek". Je me demande pourquoi ils n'avaient pas besoin d'outils de ligne de commande par rapport aux personnes Unix qui font tout leur travail avec ces outils.

La même raison que l'iPod, l'iPhone (n'importe quel téléphone d'ailleurs) et l'iPad ne le font pas: la ligne de commande n'est pas le principal canal d'interaction de l'utilisateur avec l'ordinateur sous Windows. C'est sous UNIX ou GNU / Linux - c'est pourquoi ils sont plus matures. Même argument pourquoi les postes de travail de l'interface graphique Linux ont été si détraqués pendant si longtemps par rapport à Windows (Mac OS sorte de triche ici depuis qu'ils ont obtenu la ligne de commande unix un peu gratuitement).

Je simplifie peut-être trop, mais je pense que c'est une chose culturelle:

1. Dans la culture Microsoft, les développeurs se concentrent sur l'écriture de programmes pour leurs utilisateurs . Les programmes sont tous basés sur une interface graphique.
2. Dans la culture Unix, les développeurs se concentrent sur l'écriture de programmes pour d'autres développeurs . Les programmes sont petits et visent à bien faire une chose spécifique.

Notez qu'il n'y a aucune raison pour que Microsoft puisse être le seul à écrire un shell pour Windows. Les gars qui écrivent bash sont différents des gars qui écrivent des noyaux * nix. Vous n'avez même pas besoin de privilèges root. J'ai compilé mes propres shells à utiliser lorsque je n'aimais pas celui installé par le sysadmin. S'il y avait une vraie demande pour un meilleur shell Windows, quelqu'un en aurait écrit un.

Parce qu'il n'y a jamais eu assez d'appel pour un, je suppose.

Windows Scripting Host a été installé en standard depuis Windows 98 (je suppose qu'il existait avant cela); VBScript était très capable; ou vous pourriez facilement écrire un outil en ligne de commande, qui avait accès à l'ensemble de l'API Windows.

Powershell, en termes simples, n'est qu'un autre pas dans la même direction. COM n'est plus populaire, donc WSH est devenu tout à fait un processus d'apprentissage. Mais .NET est la grande chose actuelle dans le monde Windows et apprendre Powershell à partir d'un arrière-plan .NET est relativement facile.

Mais je pense que Powershell s'est trompé en essayant de faire appel à la foule * nix, avec tous ses pseudonymes qui le font ressembler à Bash alors qu'il ne l'est clairement pas.

Mis à part les commutateurs de ligne de commande, la tuyauterie est très différente dans Powershell et est vraiment la première chose que vous devez apprendre lorsque vous la récupérez.

Et honnêtement, cela ressemble beaucoup plus à un langage de script, à la Perl, qu'à un shell, à la Bash. Il y a de sérieux problèmes si vous essayez de l'utiliser comme shell principal.

Par exemple, essayez de faire un simple vidage SVN à partir de Powershell. Il ne gère pas très bien les données binaires dans stdout. D'un autre côté, manipuler un journal SVN est un rêve absolu, grâce à son type xml intégré.

Parce qu'il n'y a pas besoin et beaucoup de peine de développer un deuxième jeu d'outils Windows parallèle.

Les shells sont rendus puissants grâce au nombre et à la puissance des programmes d'assistance sur un système GNU, tels que sed, find, xargs et al. La réimplémentation de ces outils représente beaucoup de travail, et la simple création d'une couche de conformité POSIX au-dessus de Windows s'est avérée beaucoup plus facile. Cygwin est une telle couche de conformité POSIX et répond à la plupart des besoins des utilisateurs du shell lorsqu'ils sont obligés d'utiliser Windows.

Je suppose personnellement que la communauté des développeurs qui n'est pas disposée à sauter le train en marche POSIX et Linux et qui est encore suffisamment dévouée à la programmation shell est si petite qu'il a fallu 20 ans pour développer un shell stable.

C'est une de ces questions qui, ignorant les théories du complot, n'a probablement pas de réponse unique et est le genre de chose dont les historiens pourraient discuter à jamais sans jamais trouver de réponse définitive.

Mon impression est que la puissance de la coque n'est pas immédiatement évidente. J'ai commencé la programmation sous Windows 3.1 et le shell était très peu utilisé. Tout a été fait via l'IDE Visual C ++, et je n'ai jamais regardé les makefiles et les fichiers batch DOS étaient si limités que j'ai rarement essayé d'utiliser un fichier batch pour automatiser quelque chose de plus compliqué qu'une sauvegarde de base. Aucun des livres de programmation axés sur Windows (j'ai de bons souvenirs de Petzold ) que je lisais à l'époque a discuté de l'utilisation du shell Windows pour quoi que ce soit. Ce n'est que lorsque j'ai commencé à utiliser et à programmer Linux que j'ai compris l'utilité d'un shell puissant. Je me souviens que lorsque Windows est sorti, c'était tellement excitant parce que vous n'aviez pas à utilisercommand.complus. Nous avions enfin une jolie interface avec plus d'une police et plusieurs programmes fonctionnant en même temps sans avoir besoin d'un TSR ...

Je pense que la plupart des programmeurs qui démarrent sous Windows n'ont tout simplement pas d'expérience avec un shell puissant et donc, ne ressentent pas le besoin pressant d'en implémenter un pour Windows. Les programmeurs qui travaillent sous Linux et apprécient le shell, préfèrent travailler sous Linux et ne se sentent donc pas enclins à passer du temps à travailler dans un environnement dans lequel ils ne sont pas aussi à l'aise pour en implémenter un pour Windows, surtout compte tenu (comme cela a été souligné dans une autre question) la nécessité d'implémenter également tous les outils CLI nécessaires avec le shell lui-même.

La popularité croissante de Linux est probablement la principale raison pour laquelle Microsoft a finalement mis en place un shell approprié. De plus en plus de gens se sont rendu compte de l'utilité d'un shell, il est devenu de plus en plus clair que Windows manquait d'un outil important.

Si vous considérez les shells Unix comme «décents», alors il y a eu au moins un shell pour Windows qui était «décent» depuis des décennies. Le shell Hamilton C est raisonnablement proche du shell Unix C (mais notez que le shell C n'a jamais eu une pénétration de marché particulièrement énorme sur Unix). Beaucoup de gens ont également utilisé les différents shells de JPSoft (4DOS, 4NT, maintenant appelé Take Command) depuis un certain temps - comme vous pouvez probablement le deviner d'après le nom, 4DOS remonte à l'époque MS-DOS.

Si vous insistez sur un shell distribué par Microsoft, il y a 15 ans environ, le kit de ressources Windows NT incluait un port NT du shell PD Korn ¹ , ainsi qu'un bon nombre d'utilitaires Unix-ish. Il n'en comprenait probablement pas assez pour exécuter de nombreux scripts shell sans modification, mais était suffisant pour gérer une bonne quantité d'utilisation, en particulier un peu de travail interactif.

¹ En toute honnêteté, je ne sais pas si c'était un port de cet obus exact, ou juste quelque chose de tout à fait similaire - je l'ai utilisé suffisamment pour vérifier qu'il était aussi ennuyeux que je me souvenais des obus Unix, et je l'ai laissé là .

Windows a des fonctionnalités de conception qui ne se prêtent pas aux scripts. C'est le résultat de faire de l'interface graphique le mode de fonctionnement principal. De nombreux outils n'ont pas d'interfaces de ligne de commande fonctionnelles. Sans une interface de ligne de commande décente, il est très difficile de générer un bon shell.

Souvent, les choses qui doivent être scriptées dans Windows nécessitent des clics de souris et des frappes de touches à simuler à divers endroits sur une fenêtre d'applications. Les scripts résultants peuvent être assez fragiles. Décrire où écrire un script dans un langage de commande n'est pas un exercice trivial car la géométrie pertinente n'est pas facilement disponible.

Windows n'avait pas non plus de mécanisme de canalisation fonctionnel dans les premières versions. Comme il a été décrit, le premier processus s'exécuterait et sa sortie serait enregistrée dans un fichier temporaire. Ce fichier serait utilisé comme entrée pour la commande suivante. Cela pourrait être gourmand en disque et échouerait si l'espace temporaire suffisant n'était pas disponible. Les canaux Unix transmettent les données en mémoire et planifient les processus de manière à minimiser les retards.

Lors de son lancement, en 1993, Windows NT était un déplacement de MS dans l'espace précédemment occupé par les serveurs Unix et à l'époque un gros problème a été fait concernant la compatibilité et la portabilité POSIX. Mais il n'a pas tout à fait fait le travail - au lieu de cela, ses utilisateurs étaient plus la foule de bureaux utilisant un meilleur matériel (c'était l'époque où un 486dx 50 MHz avec 32 Mo de RAM était proche de l'extrémité supérieure) et voulant un meilleur système d'exploitation. Mais ils n'étaient pas intéressés par les obus, alors tout a glissé. Au moment de Windows Server 2000, qui était une deuxième tentative sérieuse de percer ce marché, je pense que MS avait réalisé qu'ils étaient faibles du côté du shell - car les administrateurs adorent les scripts shell - mais même alors, il leur a fallu un certain temps pour gratter les démangeaisons.