Quali sono stati i motivi per cui Windows non ha mai avuto una shell decente? [chiuso]

Stavo leggendo un argomento su SO: Perché i linguaggi di scripting (es. ...) non sono adatti come linguaggi di shell? . In particolare mi è piaciuta la risposta di Jörg W Mittag , da cui ho imparato cose interessanti Windows PowerShell. Quindi dopo oltre 20 anni Windows ha finalmente una shell ben progettata (Windows 1.0 - 1985, versione stabile di PowerShell - 2009). D'altra parte i sistemi Unix hanno un sacco di varie shell dal 1978 Bourne Shell. Ho letto alcuni articoli sui colloqui di lavoro con MS e ho l'impressione di un'azienda molto "geek". Mi chiedo perché non abbiano avuto bisogno di strumenti da riga di comando rispetto alle persone Unix che svolgono tutto il loro lavoro con quegli strumenti.

Lo stesso motivo per cui l'iPod, l'iPhone (qualsiasi telefono in questione) e l'iPad non lo fanno: la riga di comando non è il canale principale di interazione dell'utente con il computer in Windows. È in UNIX o GNU / Linux - quindi è per questo che sono più maturi. Stesso argomento per cui i desktop della GUI di Linux sono stati spazzatura per così tanto tempo rispetto a Windows (tipo di trucchi per Mac OS qui da quando hanno ottenuto la linea di comando unix in modo gratuito).

Forse sto semplificando troppo, ma la considero una cosa culturale:

1. Nella cultura Microsoft, gli sviluppatori si concentrano sulla scrittura di programmi per i loro utenti . I programmi sono tutti basati sulla GUI.
2. Nella cultura Unix, gli sviluppatori si concentrano sulla scrittura di programmi per altri sviluppatori . I programmi sono piccoli e focalizzati sul fare bene una cosa specifica.

Nota che non c'è motivo per cui Microsoft possa essere l'unica a scrivere una shell per Windows. I ragazzi che scrivono bash sono diversi da quelli che scrivono kernel * nix. Non hai nemmeno bisogno dei privilegi di root. Ho compilato le mie shell da usare quando non mi piaceva quella installata da sysadmin. Se ci fosse una vera richiesta di una shell di Windows migliore, qualcuno avrebbe scritto una.

Perché non c'è mai stato abbastanza appello per uno, credo.

Windows Scripting Host è stato installato come standard da Windows 98 (suppongo fosse già in circolazione); VBScript era molto capace; oppure potresti facilmente scrivere uno strumento da riga di comando, che aveva accesso all'intera API di Windows.

Powershell, in parole semplici, è solo un altro passo nella stessa direzione. COM non è più popolare, quindi WSH è diventato un processo di apprendimento. Ma .NET è l'attuale Big Thing nel mondo Windows e imparare Powershell da un background .NET è relativamente semplice.

Un posto in cui penso che Powershell sia andato storto è nel tentativo di fare appello anche alla folla * nix, con tutti i suoi alias che la fanno sembrare Bash quando chiaramente non lo è.

A parte le opzioni della riga di comando, il piping è molto diverso in Powershell ed è davvero la prima cosa che dovresti imparare quando lo raccogli.

E onestamente, è molto più simile a un linguaggio di scripting, a la Perl, che a una shell, a la Bash. Ci sono alcuni gotcha seri se provi ad usarlo come shell principale.

Ad esempio, prova a fare un semplice dump SVN da Powershell. Non gestisce molto bene i dati binari in stdout. D'altra parte, manipolare un registro SVN è un sogno assoluto, grazie al suo tipo xml incorporato.

Perché c'è poco bisogno e molto dolore nello sviluppo di un secondo set di strumenti di Windows parallelo.

Le conchiglie sono rese potenti dal numero e dalla potenza dei programmi di supporto su un sistema GNU, come sed, find, xargs et al. La reimplementazione di questi strumenti richiede molto lavoro e la semplice creazione di un livello di conformità POSIX su Windows si è dimostrata molto più semplice. Cygwin è un tale livello di conformità POSIX e fornisce la maggior parte delle esigenze degli utenti della shell quando sono costretti a utilizzare Windows.

Personalmente immagino che la comunità di sviluppatori che non è disposta a saltare sul carrozzone POSIX e Linux e che è ancora sufficientemente dedita alla programmazione della shell sia così piccola che ci sono voluti 20 anni per sviluppare una shell stabile.

Questa è una di quelle domande che, ignorando le teorie della cospirazione, probabilmente non hanno una sola risposta ed è il tipo di cose su cui gli storici potrebbero discutere per sempre senza mai trovare una risposta definitiva.

La mia impressione è che il potere della shell non sia immediatamente evidente. Ho iniziato a programmare in Windows 3.1 e la shell non utilizzava molto. Tutto è stato fatto tramite l'IDE di Visual C ++ e non ho mai visto makefile e file batch DOS così limitati che raramente ho provato a usare un file batch per automatizzare qualcosa di più complicato di un backup di base. Nessuno dei libri di programmazione focalizzati su Windows (ho ricordi affettuosi di Petzold ) che stavo leggendo all'epoca discutevo usando la shell di Windows per qualsiasi cosa. Solo quando ho iniziato a usare e programmare Linux ho capito quanto potesse essere utile una shell potente. Ricordo che quando uscì Windows era così eccitante perché non dovevi usare il vecchiocommand.compiù. Finalmente abbiamo avuto un'interfaccia carina con più di un font e più programmi in esecuzione contemporaneamente senza la necessità di un TSR ...

Penso che la maggior parte dei programmatori che iniziano in Windows non abbiano esperienza con una shell potente e quindi non sentono il bisogno urgente di implementarne una per Windows. I programmatori che lavorano in Linux e apprezzano la shell, preferiscono lavorare in Linux e quindi non si sentono inclini a passare il tempo a lavorare in un ambiente in cui non sono a proprio agio nell'implementarne uno per Windows, soprattutto considerando (come è stato sottolineato in un'altra domanda) la necessità di implementare anche tutti gli strumenti della CLI necessari insieme alla shell stessa.

La crescente popolarità di Linux è, probabilmente, la ragione principale per cui Microsoft ha finalmente inserito una shell corretta. Man mano che sempre più persone si rendevano conto di cosa fosse utile una shell, divenne sempre più chiaro che a Windows mancava uno strumento importante.

Se consideri le shell Unix "decenti", allora c'è stata almeno una shell per Windows che è stata "decente" per decenni. La shell Hamilton C è ragionevolmente vicina alla shell Unix C (sebbene si noti che la shell C non ha mai avuto un'enorme penetrazione del mercato su Unix). Molte persone hanno anche usato le varie shell di JPSoft (4DOS, 4NT, ora chiamato Take Command) per un bel po 'di tempo - come probabilmente si può immaginare dal nome, 4DOS risale ai tempi di MS-DOS.

Se insisti su una shell distribuita da Microsoft, circa 15 anni fa, il kit di risorse di Windows NT includeva una porta NT della shell Korn PD ¹ , insieme a un numero equo di utility Unix-ish. Probabilmente non includeva abbastanza per eseguire molti script di shell senza modifiche, ma era abbastanza per gestire un buon uso, in particolare un bel po 'di lavoro interattivo.

¹ In tutta onestà, non so che era una porta di quella shell esatta, o semplicemente qualcosa di abbastanza simile - l'ho usato abbastanza per verificare che fosse fastidioso come ricordavo le shell Unix, e l'ho lasciato a quello .

Windows ha funzionalità di progettazione che non si prestano allo scripting. Questo è il risultato di rendere l'interfaccia grafica la modalità operativa principale. Molti strumenti non dispongono di interfacce a riga di comando funzionali. Senza un'interfaccia decente da riga di comando è molto difficile generare una buona shell.

Spesso le cose che devono essere scritte in Windows richiedono che i clic del mouse e i tasti vengano simulati in varie posizioni nella finestra delle applicazioni. Gli script risultanti possono essere piuttosto fragili. Descrivere dove scrivere in un linguaggio di comando non è un esercizio banale poiché la geometria pertinente non è prontamente disponibile.

Windows inoltre non aveva un meccanismo di piping funzionale nelle prime versioni. Come è stato descritto, il primo processo verrà eseguito e il suo output verrà salvato in un file temporaneo. Quel file verrebbe utilizzato come input per il comando successivo. Ciò potrebbe richiedere un utilizzo intensivo del disco e non riuscirebbe se non fosse disponibile spazio temporaneo sufficiente. Le pipe Unix trasmettono i dati in memoria e pianificano i processi in modo da ridurre al minimo i ritardi.

Quando è stato lanciato, nel 1993, Windows NT è stato un passaggio di MS nello spazio precedentemente occupato dai server Unix e all'epoca è stato fatto un grosso problema sulla compatibilità e sulla portabilità di POSIX. Ma non ha fatto esattamente il suo lavoro - invece i suoi utenti erano più la folla del desktop che utilizzava un hardware migliore (erano i giorni in cui un 486dx 50MHz con 32 MB di RAM era vicino alla fascia alta) e desiderava un sistema operativo migliore. Ma non erano interessati alle conchiglie, quindi tutti sono scivolati. Al tempo di Windows Server 2000, che era un secondo serio tentativo di decifrare questo mercato, penso che MS avesse capito che erano deboli sul lato shell - poiché gli amministratori amano gli script di shell - ma anche allora ci è voluto del tempo per grattarsi il prurito.