Perché bash è la shell predefinita nella maggior parte dei sistemi operativi?

Perché bash è la shell predefinita nella maggior parte dei sistemi operativi (Ubuntu, Fedora, OSX, ecc.)? Perché molti utenti avanzati usano principalmente zsh? Se è così buono, perché non è l'impostazione predefinita?

Uso entrambi Non vedo differenze per tutte le mie attività sono semplici :)

Ho letto un po 'su questo e la conclusione sembra essere che è la shell predefinita di GNU (utilizzata dalla maggior parte dei sistemi operativi basati su Linux), e quindi viene semplicemente impacchettata come parte di GNU, pur avendo anche 20 anni di sviluppo alle spalle che lo rendono stabile e ben arrotondato, è semplicemente il migliore tuttofare, per soddisfare le esigenze di tutti tranne gli utenti più avanzati.

Per di più, leggi Perché bash è standard su Linux? (la stessa domanda su Unix e Linux).

Solo per aggiungere un po 'di più a questo, ci sono molte altre shell da provare, se sei interessato, eccone alcune da questa risposta :

• zsh ha strutture interattive più avanzate, ma alcune stranezze quando si tratta di script (meno ora che ai tempi). All'inizio della metà degli anni '90, quando Linux era agli inizi, zsh era praticamente sconosciuto.

• Ksh era lo standard di fatto per gli uffici commerciali dalla metà degli anni '80, ma era un software proprietario fino al 2000, quindi non un'opzione su Linux. Inoltre, ksh aveva capacità di modifica della riga di comando inferiori a quelle di bash.

• Pdksh , un clone gratuito di ksh, sarebbe stato un'opzione, ma non era ben noto e aveva scarse capacità di edizione della riga di comando. (Pdksh non è più un progetto molto attivo, anche se è ancora usato in alcuni BSD, ora che ATT ksh è gratuito.)

• Alcune distribuzioni installano una variante di cenere come /bin/sh. Ash (con il quale intendo una qualsiasi delle famiglie di shell sciolte chiamate ash) è progettato per essere piccolo e veloce, senza funzionalità interattive (è solo per la modifica degli script). Il risveglio della cenere è relativamente recente; negli anni '90 le varianti esistenti mancavano di molte funzionalità.

• Tcsh era la shell interattiva più avanzata fino a quando non è arrivato zsh, ma è incompatibile con sh e non così buono con gli script .

La Bourne Shell ( sh back in the day) del ramo AT&T di Unix è stata migliorata e sostituita dalla Korn Shell, ksh . ksh è uscito anche da AT&T Bell Labs e non era GPL (la versione attuale è Eclipse Public License). C-shell, csh è uscito dalla versione Berkeley di Unix e non era anche GPL (licenza BSD) e utilizzava anche una sintassi diversa da sh. La Z-shell, zsh è un miglioramento su sh ma non su GPL (licenza simile al MIT). Bash è stato un miglioramento su sh, ha usato GPL e GNU. Solo su licenza Bash sarebbe stata probabilmente la scelta per un sistema operativo GPL. Soprattutto con un guscio che è una parte centrale di una distribuzione.

Ma Bash era anche un progetto GNU, che gli dava, credo, uno sviluppo più attivo e rendeva i contributi più facili di un prodotto legacy di Berkeley Unix o AT&T Unix. Un ottimo caso potrebbe essere che zsh sia ed è stata una shell migliore di Bash, ma non abbastanza per superare la sua diversa licenza e lo stato del progetto non GNU.

All'epoca in cui le distro Linux apparivano per la prima volta e sceglievano la loro shell predefinita (dalla prima alla metà degli anni '90), non esisteva github (2008) o persino un SourceForge (1999). A quel punto, penso che i progetti GNU abbiano avuto un reale vantaggio rispetto ai progetti non GNU nel farsi notare, disegnare e includere nuovi sviluppatori. Quindi le distro potrebbero guardare Z-shell come meglio, ma anche aspettarsi che Bash ottenga un buon supporto e manutenzione in futuro, e abbia anche più funzionalità aggiunte, che gli consentano di raggiungere zsh.

Ora che Bash ha avuto anni di status predefinito, è diventato uno standard defacto, con libri scritti al riguardo. C'è un libro che copre sia Bash che Z-shell , ma nessun libro che lo copre esclusivamente, mentre ce ne sono molti che lo fanno per Bash.

E a questo punto, se le distro cambiassero il valore predefinito per gli aggiornamenti di un sistema esistente, si romperanno le configurazioni poiché alcuni file di inizializzazione hanno nomi diversi (ad es. .Bashrc contro .zshrc) e il contenuto dei file potrebbe avere sintassi incompatibile. Quindi sarebbero molto riluttanti a farlo, lasciando nuovi download con zsh come predefinito e gli aggiornamenti con bash. Due impostazioni predefinite diverse per la stessa distribuzione sono qualcosa che probabilmente non vogliono supportare e che anche gli utenti / aziende non vogliono occuparsi.

I linguaggi della shell Unix sono tutti brutti. Alcuni in particolare ( csh), alcuni forse un po 'meno ( ksh? Non lo so in realtà), ma in realtà quando si tratta di aspetti come la leggibilità e la rigidità per grandi progetti, nessuno di essi può avvicinarsi a linguaggi per scopi generali ben progettati come Python, C # o Haskell. Quindi, quando vuoi qualcosa di solido, non sceglierai mai nessuno dei sapori della conchiglia.

Li scegli quando vuoi fare rapidamente cose semplici. Per questo, hai bisogno di:

• Sintassi concisa e coerenza sufficiente per poterlo effettivamente memorizzare (è difficile cercare operatori di stenografia). Importa molto se la tua shell è installata ovunque, perché in realtà preferiresti non memorizzare più di uno di questi mostri kludge.
• Buone funzionalità interattive, quindi puoi hackerare direttamente il terminale e far funzionare le cose senza dover passare da più file di script.
• La possibilità di catturare qualsiasi frammento di script da qualsiasi luogo e farlo funzionare. shla compatibilità è un grande vantaggio qui, e ancora una volta più popolare è, meglio è.

Quindi, vedete, la popolarità è piuttosto un punto più importante in queste lingue di shell rispetto alle lingue di uso generale. Quindi, anche se kshè un po '"migliore" come linguaggio in sé, non c'è davvero tanto vantaggio nell'usarlo sebash è solo un po' più popolare (che era, nel settore rilevante, poiché è stato scelto per la prima volta come predefinito per GNU).

Le persone che effettuano il passaggio ne sono consapevoli e hanno abbastanza esperienza per gestire facilmente il passaggio alla shell preferita. OTOH, un novellino che è costretto a lavorare con una shell meno popolare sarà rapidamente confuso se chiedono qualcosa su Internet e non funziona. Quindi, qualsiasi distribuzione che non sia rivolta solo ai veterani di Unix corre un certo rischio se fa qualcosa di diverso bashdallo standard, un passo dal quale relativamente poche persone trarrebbero beneficio (e solo un po ').

1. Era lì quando era necessario
2. Ha abbastanza piacere per gli occhi che gli utenti principianti possono passare una settimana a personalizzare il loro prompt.
3. I casi d'uso comuni sono abbastanza buoni (il più comune è avviare un singolo comando)
4. Dove non è abbastanza buono perl, Python e Lua possono occupare il gioco.
5. perl crea una terribile shell interattiva
6. sebbene i pesci, i ksh o gli zsh possano teoricamente essere un guscio migliore, non ci sono abbastanza miglioramenti da disturbare quando il perl funziona così bene o la portabilità è un problema, quindi sto comunque prendendo di mira il trattino.

"Massa critica" è la risposta principale, IMO. Bash non è solo per il lavoro da riga di comando, è anche per gli script e c'è un numero enorme, enorme di script Bash là fuori. Non importa quanto sia ora migliore un'alternativa per l'interazione, la necessità di essere in grado di "collegare e riprodurre" quegli script supera questi vantaggi. Come tale, l'unica shell che può realisticamente disinserire Bash ora è quella che è completamente compatibile con le versioni precedenti e il candidato più probabile per questo è ... la prossima versione di Bash.