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

Lo stesso motivo per cui iPod, iPhone (qualsiasi telefono per quella materia) e 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 - ecco perché sono più maturi. Lo stesso argomento per cui i desktop della GUI di linux sono stati spazzatura per così tanto tempo rispetto a Windows (un tipo di cheat Mac OS qui dato che hanno un po 'di riga di comando unix gratis).

Forse sto semplificando eccessivamente, 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 su GUI.
2. Nella cultura Unix, gli sviluppatori si concentrano sulla scrittura di programmi per altri sviluppatori . I programmi sono piccoli e mirano a fare bene una cosa specifica.

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

Perché non c'è mai stata abbastanza chiamata per uno, immagino.

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

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

In un posto, penso che Powershell sia andato storto anche se sta cercando di attirare il pubblico di * nix, con tutti i suoi alias che lo fanno sembrare Bash quando non lo è.

Oltre agli switch a linea di comando, le pipe sono very diverse in Powershell ed è davvero la prima cosa che dovresti imparare quando la raccogli.

E onestamente, è molto più simile a un linguaggio di scripting, a la Perl, che a un guscio, a la Bash. Ci sono alcuni trucchi seri se cerchi di 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 di XML incorporato.

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

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

Personalmente ritengo che la comunità di sviluppatori che non è disposta a saltare il carrozzino POSIX e Linux e che sia 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 ha una singola risposta ed è il tipo di cosa che gli storici potrebbero discutere per sempre senza mai trovare una risposta definitiva.

La mia impressione è che la potenza della shell non sia immediatamente evidente. Ho iniziato a programmare su Windows 3.1 e ho usato pochissimo la shell. Tutto è stato fatto attraverso l'IDE di Visual C ++, e non ho mai guardato i makefile e i file batch di DOS erano così limitato 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 incentrati su Windows (ho bei ricordi di Petzold ) stavo leggendo al momento discusso usando la shell di Windows per qualsiasi cosa. Non è stato fino a quando ho iniziato a usare e programmare Linux che ho capito quanto potesse essere utile una potente shell. Ricordo che quando uscì Windows era così eccitante perché non dovevi più usare% vecchio%% di più. Abbiamo finalmente 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 potente shell e quindi non sentano la necessità 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 propensi a passare il tempo lavorando in un ambiente in cui non sono così a loro agio per implementare uno per Windows, specialmente considerando (come è stato sottolineato in un'altra domanda) la necessità di implementare anche tutti gli strumenti CLI necessari insieme alla shell stessa.

La crescente popolarità di Linux è, probabilmente, la ragione principale per cui Microsoft ha finalmente inserito una shell adeguata. Man mano che sempre più persone hanno capito che cosa è utile una shell, è diventato sempre più chiaro che a Windows mancava uno strumento importante.

Windows ha funzionalità di progettazione che non si prestano allo scripting. Questo è il risultato del fare dell'interfaccia grafica la modalità operativa principale. Molti strumenti non hanno interfacce funzionali a linea di comando. Senza una discreta interfaccia a riga di comando è molto difficile generare una buona shell.

Spesso le cose che devono essere programmate in Windows richiedono che i clic del mouse e le sequenze di tasti siano simulati in varie posizioni in una finestra di applicazioni. Gli script risultanti possono essere abbastanza fragili. Descrivere dove scrivere in una lingua di comando non è un esercizio banale in quanto la geometria pertinente non è facilmente disponibile.

Anche Windows non aveva un meccanismo di piping funzionale nelle prime versioni. Come è stato descritto, il primo processo verrebbe eseguito e il suo output verrebbe salvato in un file temporaneo. Quel file sarebbe usato come input per il prossimo comando. Questo potrebbe essere un disco intenso e fallirebbe se non fosse disponibile spazio temporaneo sufficiente. I pipe Unix passano i dati in memoria e pianificano i processi in modo da minimizzare i ritardi.

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

Se si insiste su una shell distribuita da Microsoft, 15 anni fa circa il kit di risorse di Windows NT includeva una porta NT di PD Korn shell ¹ , insieme a un numero discreto di utilità Unix-ish. Probabilmente non includeva abbastanza per eseguire molti script di shell senza modifiche, ma era sufficiente per gestire una buona dose di utilizzo, specialmente un bel po 'di lavoro interattivo.

¹ In tutta onestà, non so che si trattasse di una porta di quel guscio esatto, o solo di qualcosa di abbastanza simile - l'ho usato abbastanza per verificare che fosse fastidioso come me ricordava che le shell Unix erano e l'hanno lasciato a questo.

Quando fu lanciato, nel 1993, Windows NT fu una mossa della MS nello spazio precedentemente occupato dai server Unix e al momento fu fatto un grosso problema sulla compatibilità e la portabilità di POSIX. Ma non ha fatto proprio il lavoro - invece gli utenti erano più la folla desktop che utilizzava hardware migliore (questi erano i giorni in cui un 486dx 50MHz con 32MB di RAM era vicino alla fascia alta) e volevano un sistema operativo migliore. Ma non erano interessati alle conchiglie, quindi tutto scivolò. Al momento di Windows Server 2000, che è stato un secondo serio tentativo di crackare questo mercato, penso che MS si sia resa conto che erano deboli dal lato shell - come gli amministratori amano gli script di shell - ma anche in quel momento ci sono voluti un po 'di tempo per scalfire il prurito.