Warum ist Bash überall (in den meisten, wenn nicht allen Linux-Distributionen)?


50

Bash wird standardmäßig in jeder Linux-Distribution verwendet, die ich ausprobiert habe, über Alternativen wie Z-Shell (zsh). Gibt es dafür einen technischen oder historischen Grund?


1
Es ist nicht. Auf meinem FreeBSD-System ist tcsh die Standard-Shell!

54
Ihr FreeBSD-System ist keine Linux-Distribution.

8
Gott bewahre, dass es eine gewisse Übereinstimmung zwischen den Distributionen gibt ...
OMG Ponies

4
Nein, aber es gehört "überall" :)

Antworten:


106

Geschichte (erworben nicht durch Forschung, sondern durch viel zu viel Zeit mit Leuten von Bell Labs):

  1. Am Anfang (wenn Sie den Anfang als Unix-Version 7 ansehen) war die Bourne-Shell. Steve Bourne war der erste, der zeigte, dass die Shell, die die Interaktion des Benutzers kontrollierte, ein Benutzerprogramm und kein spezieller Teil des Betriebssystems sein konnte. Ein historischer Durchbruch. Die Shell selbst war für die Skripterstellung relativ sauber, verfügte jedoch über keine Befehlszeilenbearbeitung oder Auftragssteuerung. Bournes Einführung in die Unix-Shell ist auch heute noch für Anfänger nützlich.

    Bearbeiten : Ich habe einige "Vorgeschichte" von Ken Thompson und John Mashey, auch von Multics ignoriert. Ich bin mir sicher, dass Bourne über all diese Arbeiten Bescheid wusste (er war im selben Labor, 1127, bei Bell Labs), aber Bournes Shell war endgültig, und die früheren Arbeiten hatten nur einen geringen Einfluss, außer wie von Steve Bourne interpretiert. Zum Beispiel, obwohl Ken später den Plan 9 C-Compiler schrieb und einen großen Einfluss auf Plan 9 hatte, erwähnt Tom Duffs Artikel über die Plan 9-Shell (rc) nur die Bourne-Shell, nicht die von Thompson.

  2. Die Shell ist nur ein Benutzerprogramm, also kann jeder eines schreiben. Als Version 7 Unix in New Jersey erstellt wurde, wurde Berkeley Unix in Kalifornien erstellt. Bill Joy von Berkeley schrieb cshdie C-Shell. Joy fügte Job-Kontrolle und Verlauf sowie spätere Befehlszeilen-Bearbeitung hinzu, war sich jedoch Bournes Arbeit nicht bewusst und stützte seine Sprache daher auf die Thompson-Shell (die ich im vorherigen Aufzählungszeichen als "prähistorisch" betrachtete). Die Unix-Community mochte die Jobkontrolle, aber sie mochte auch Bournes Sprache. Eine nicht besonders gute Polemik gegen die Sprache csh finden Sie unter Csh-Programmierung als schädlich . Eine Zeit lang verwendeten viele Leute cshinteraktiv die Funktionen zur Auftragssteuerung und zum Verlauf, aber sie verwendeten Bournes sh, um Skripte zu schreiben. Diese Situation war weniger als ideal.

    Edit : Vielen Dank an DigitalRoss, der mich über die Chronologie von csh. Da ich meine Ausbildung von Leuten erhielt, die BSD als "Berkeley-Häresie" bezeichnen, waren mir die Fakten dort ziemlich knapp.

  3. Dave Korn von Bell Labs hat die Bourne-Shell brillant überarbeitet, um die Korn-Shell (ksh) zu erstellen. Es war vollständig abwärtskompatibel mit der Bourne-Shell sh, bot jedoch eine Fülle von unschätzbaren Verbesserungen. kshwurde zur Basis eines POSIX-Standards und wurde standardmäßig mit Sun-Software ausgeliefert. (Dies trotz der Tatsache, dass Bill Joy Berkeley verließ, um Sun zu gründen, und einer ihrer führenden Software-Leute war.)

  4. Bell Labs und AT & T schaffen es dummerweise nicht, kshOpen Source zu machen . ksh88ist weit verbreitet, aber Quellen zu haben ist nicht legal. Bestimmte Menschen werden so süchtig, dass sie zu digitalen Kriminellen werden.

    Edit : War das wirklich so doof? Schwer zu wissen. Berkeley gab bereits Unix ab, und andere Unternehmen sollten bald folgen, aber dies war noch die Ära, in der die Corporate Masters daran glaubten, Unix anzugreifen. Aber das Ergebnis: AT & T Unix ist tot, nachdem es mehrmals an verschiedene Parteien verkauft wurde. BSD und seine Derivate sind am Leben und in Ordnung, aber diese neuen Dinge, "Linux" und "GNU" genannt, haben einen gewaltigen Anteil an Mindshare, der einst Bell Labs gehörte.

  5. Die Free Software Foundation erstellt eine "Reinraum" -Implementierung einer POSIX-Shell von Grund auf, wobei alle Ideen von Dave Korn auf den neuesten Stand gebracht und im üblichen FSF-Stil um eigene neue Funktionen wie die programmierbare Vervollständigung ergänzt werden. Sie nennen es die "Bourne again" Shell oder bash.

  6. Mitte der 1990er Jahre war AT & T Open Source ksh93, aber bis dahin ist es zu spät für eine breite Akzeptanz. Die Lizenzvereinbarung ist seltsamerweise nicht standardgemäß. bashund kshdivergieren und erreichen kshniemals einen Marktanteil, der seinem Platz in der Geschichte entspricht.

Unterricht:

  • Das erste Produkt, das für den Markt geeignet ist, gewinnt (sh).

  • Die Leute lieben neue Funktionen (Auftragssteuerung, Befehlsabschluss), aber sie lieben sie noch mehr, wenn ihre alten Skripte weiter funktionieren.

  • Edit : Professorinnen und Professoren der Ingenieurwissenschaften sollten Geschichte Wissenschaftshistorikern überlassen :-)


Ich denke, Sie haben wirklich die vollständigste und genaueste Erklärung für die Popularität von Bash über alles andere. Ich habe Umgebungen gesehen, in denen standardmäßig zsh verwendet wird, und ich hasse sie, weil die gesamte Syntax ein wenig abweicht und ich es nicht herausfinden kann oder Fehler mache.

Bullet (1) muss korrigiert werden: Bevor die Bourne-Shell die Mashey-Shell war, und bevor die Mashey-Shell die Ur-Shell, die Ken Thompson-Shell. Siehe en.wikipedia.org/wiki/Unix_shell
Jim Ferrans

2
Ohne Norman speziell zu beschuldigen, gibt es hier viele Ungenauigkeiten. Ken Thompson schrieb die erste Shell, die die einzige Shell über V6 war und parallel in V7 und 32V verwendet wurde. Stephen Bourne war nicht der "erste" Shellwriter, er hat die KT-Shell umgeschrieben. Csh hatte keine Job-Kontrolle bis 4.1BSD, obwohl es die erste Shell war, die es bekam. Csh änderte keine Shell-Syntax, es war abwärtskompatibel mit der V6-Shell, ebenso wie die Bourne-Shell. Fast der gesamte Code wurde damals lizenziert. Was genau war blöd daran, Lizenzgebühren für Unix zu erheben?
DigitalRoss

2
Ich erkläre das wahrscheinlich nicht sehr gut, lass es mich noch einmal versuchen. Csh geht Bourne voraus , oder spätestens war eine parallele Implementierung einen Kontinent entfernt. (Vor dem Internet war das wichtig.) Ich saß gelegentlich neben Bill Joy in Cory Hall, als er es schrieb. Ich kann Ihnen absolut versichern, dass er es auf V6 geschrieben hat. Wie gesagt, csh (und Bourne) sind V6-Thompson-abwärtskompatibel, da dies alles war, was beim Schreiben vorhanden war. Natürlich ist es nicht Bourne-kompatibel, AFAIK Bill Joys Talente beinhalteten nicht das Sehen der Zukunft
DigitalRoss

1
Haben Sie nicht bashdie Idee der programmierbaren Fertigstellung übernommen tcsh?

46

Bash hat zwei völlig verschiedene Dinge zu bieten.

  1. Es ist eine feine Muschel. Es ist eine von vielleicht zwei Shells (die andere ist zsh), die einige der coolen cshFunktionen wie die !Ersetzung von History in die Posix-Syntax integrieren. Es hat viele Erweiterungen, einschließlich Arrays.

  2. Es ist die FSF / GNU-Shell. In der Open Source-Welt ist dies eine Art Gütesiegel.

Ich sollte auch hinzufügen, dass es nicht immer der Standard ist. ashwird oft als / bin / sh verwendet, so dass es sich bashzwar um die interaktive Shell handelt, ashes sich jedoch um die Shell handelt, mit der die Befehlsdatei nur ausgeführt wird. Dies liegt daran, dass ashes kleiner und schneller ist und die Posix-Funktionen enthält, sodass es sich um eine geeignete Teilmenge handelt. Die Verwendung ashals interaktive Shell ist manchmal problematisch. Auf NetBSD zum Beispiel funktioniert es gut, weil es dort mit allen Funktionen gebaut ist. Es ist eine Art von einer Shell, während bashes sich um ein externes Paket handelt. Da Linux ashnormalerweise als nicht interaktiv eingestuft wird, kompilieren sie es ohne den Verlauf und ohne die (wichtige) Zeilenbearbeitung mit der Theorie, dass es nur zum Ausführen dieser riesigen gnu configureSkripte verwendet wird.

Geschichte von zwei Muscheln

Die wahre Geschichte der Muschel

UPDATE: Es gibt eine ungenaue Historie, in der die Shell von Ort zu Ort im Web kopiert wird, und die Leute glauben es verständlicherweise. Ich werde versuchen, eine genaue Version anzugeben und ein paar Links bereitzustellen, um dies hier zu begründen.

  1. Die erste Shell war mit Sicherheit nicht die Bourne-Shell, sondern wurde von Ken Thompson selbst geschrieben und in V6 verteilt, der Version, die AT & T an verschiedene Universitäten und Regierungslabors gesendet hat. Dies ist es, was Unix auf die Karte setzt. Es hatte alle Grundlagen, <, >, >>, |, &aber es hatte nur eine einfache gotoSteuerungssyntax über ein externes Programm, das nach Standardeingaben suchte. Es gab damals keine komplexen Shell-Skripte. Spätere Shells würden die Befehlseingabe auf einem separaten fd öffnen. Es mag heute einfach aussehen, aber in dem Horrorfilm aus den 1970er Jahren war es das Beste auf der Welt. Ob Sie es glauben oder nicht, diese alte Shell hat heute ihren eigenen Twitter-Stream und natürlich eine Homepage .
  2. Die zweite Schale wurde csh, geschrieben (war vi) von Bill Joy bei UCB. Dies war vor der GNU-Readline und der NetBSD-Editline, daher schien es völlig vernünftig, mit der !Syntax Geschichte zu schreiben . Csh fügte die meisten der heutigen Shell-Funktionen hinzu, jedoch mit csh-Syntax. csh hat keine Syntax geändert, weder unentgeltlich noch auf andere Weise. Es war tatsächlich abwärtskompatibel mit der Thompson-Shell und enthielt ursprünglich TS-Quellcode.
  3. Die dritte Shell war die Bourne-Shell mit unterschiedlicher Syntax. Unix wurde parallel bei UCB und AT & T entwickelt. Diese Shell hatte einen seltsamen Speicher-Allokator (ich glaube, sie hat einfach mehr Speicher verwendet, SIGSEGV blockiert, einen neuen brk (2) ausgeführt und es dann erneut versucht), der es schwierig machte, auf neuen Unix-Ports zu laufen, oshund deshalb cshfür einige Zeit populär blieb . Es gab kein Internet und es war lizenzierte Software, daher ist es möglich, dass Stephen Bourne nichts über Joys Shell wusste und Joy sicherlich nichts über Bourne wusste. Es ist möglich, dass sich die beiden Shells zum ersten Mal trafen, als UCB eine VAX und eine Vorabversion des jetzt vergessenen Unix / 32V bekam . Ich erinnere mich, wie Bill sich über die Speicherzuweisung beschwerte. Beachten Sie, dass beide Shells abwärtskompatibel zur V6-Shell warenSie haben die Syntax einfach in verschiedene Richtungen erweitert.
  4. Nun gab es wirklich mehrere inkompatible Shells, zu denen AT & T die Bourne-kompatiblen hinzufügte ksh. Irgendwann cshhatte semi-verfügbaren Quellcode, aber es wurde in einem Rechtsstreit zwischen AT & T und der University of California gebunden . Dennoch waren dies die ruhmreichen Tage von BSD Unix, als hoch entwickelte Unternehmen, die sich die Gebühr von 50.000 USD leisten konnten, die AT & T-Lizenz kauften, aber die 4.x-BSD-Distributionen installierten, und die Universitäten diese kostenlos erhielten.
  5. In dieser Situation mit vielen rechtlichen und technischen Problemen wurden verschiedene unabhängige Implementierungen vorgenommen. Mindestens so viele gingen mit der cshSyntax wie mit der Bourne-Shell-Syntax, und einige verschmolzen die beiden. Sie haben zumindest tcsh, zsh, bash, und ash. Die Bourne-Syntax war "offiziell", da sie Teil von AT & T-Releases war, aber damals war BSD ziemlich wichtig, und Sun, ursprünglich BSD, verteilte eine ganze Menge der Unix-SW, auf die die Welt stieß.
  6. Teilweise wegen der USL-Klage hatten die FSF und Linux ein offenes Feld. In der Zwischenzeit hatte AT & T es geschafft, einen Kampf mit einer der wenigen Entitäten auf der Erde zu führen, die größer waren als sie (der Bundesstaat Kalifornien), und am Ende gewannen sie die Klage nicht Fundament. Aber damals waren Linux und Bash überall, und so ist BSD heute eine Nische.
  7. Schließlich ist bash eine gute Shell (obwohl sie von ihrem ursprünglichen Autor anscheinend privat abgelehnt wurde) und verdient die Anerkennung für ihren eigenen Erfolg. csh wäre von tcsh und zsh in den Schatten gestellt worden, selbst wenn ash, bash und ksh den Syntaxkrieg nicht gewonnen hätten.

Außerdem muss / bin / sh statisch verknüpft sein.

Wenn etwas drin ist /binund /sbindavon abhängt /usr, ist es kaputt und muss repariert werden. sie sollten nur von Bibliotheken in abhängen /lib. loginBenötigt nur PAM; Die "neuere API", die dynamische Bibliotheken benötigt, wäre NSS. "Trend zu"? NetBSD 2.0 ist bereits auf ein voll dynamisches /binund vor /sbin5 Jahren auf FreeBSD 5.2 und noch länger auf Linux umgestiegen ... nun, das variiert je nach Distribution, aber das ist auch schon lange her.
ephemient

2
Ich möchte sehr deutlich machen, dass meine Antwort meine ursprüngliche Arbeit ist. Es wurden keine Wörter von irgendwoher kopiert .
Norman Ramsey

1
Klar, ich wollte nicht, dass du es eingefügt hast, nur, dass es viele Fehlinformationen gibt und ich wollte dich nicht dafür verprügeln, dass du eine bereits missverstandene Geschichte gemeldet hast.
DigitalRoss

6

Hinzufügen zu dem, was @DigitalRoss gesagt hat

  • Bash ist ein vollständiger Superset-Ersatz für posix-sh, auch wenn er so aufgerufen wird, dass / bin / sh posix-sh vollständig emuliert. Posix-sh war der "Standard" für kommerzielle Unix-Systeme als Common-Denominator-Shell. Also, etwas, das dort beginnt und darauf aufbaut, fängt mit viel an.

4

Weil Linux nur der Kernel (und das erforderliche Supportmaterial) ist, während GNU alle grundlegenden Unix-Software-Klone bereitstellt (oder bereitstellte), die das, was wir als "Linux" bezeichnen, nutzbar machen. Bash ist die Shell des GNU-Projekts, die als Klon der älteren Bourne- Shell (sh) von Unix Version 7 geschrieben wurde.


er fragt nicht "warum gibt es ein shell programm"
hasen

@hasen j: Die Frage wird gestellt, ob es einen historischen Grund gibt, warum alle Linux-Systeme, die er verwendet hat, standardmäßig Bash als Shell verwenden.
Bettelt

2
@hasen j: bettelt antwortet nicht "warum gibt es ein shell programm". Sie haben den Punkt der Antwort verpasst, ebenso wie alle anderen SO-Wichser.

1

Laut einer Umfrage von unix.com ist es ksh nicht viel voraus.
/ bin / sh 83 8,96%
/ bin / csh 36 3,89%
/ bin / ksh 370 39,96%
/ bin / tcsh 36 3,89%
/ bin / bash 401 43,30%


0

Bash ist aufgrund seiner umfangreichen Funktionen weit verbreitet. Es übernimmt auch Funktionen aus anderen Shells wie C-Shell und Korn-Shell. Bitte werfen Sie einen Blick auf diese Funktionen.


0

Weil 'bash' zu 100% mit 'sh / ksh' kompatibel ist und 'ksh' die POSIX-Shell ist.

Wenn Sie also ein POSIX-kompatibles System möchten und Linux verwenden, verwenden Sie bash.

Wenn Sie unter einem kommerziellen Unix arbeiten, erhalten Sie in der Regel ksh als Standardshell (manchmal einfach nur altes sh). Aus irgendeinem Grund verwendet Sun immer noch standardmäßig die csh c-shell von flakey.

Der Vorteil ist die Portabilität .sh, die für HP-UX oder AIX geschrieben wurde, hat eine gute Chance, als Linux-Bash ohne Änderungen ausgeführt zu werden.


kshist nicht die POSIX-Shell . Es gibt keine POSIX-Shell . Es gibt Shells, die der POSIX-Spezifikation entsprechen, die ksheine von ihnen ist, aber keineswegs die einzige.

0

Und zu allen anderen Antworten hinzuzufügen: zshsoll nicht abwärtskompatibel sein. Sie können es wahrscheinlich so einrichten, dass es kompatibel ist, aber dann verlieren Sie seine Funktionen.

Ich benutze zshals meine normale interaktive Shell, aber bash/ dashscheinen gesund zu mir wie ein Shell - Skript - Sprachen; Sie machen weniger Magie und sind vorhersehbarer. Dies ist für mich wichtiger, wenn ich ein Skript schreibe, das mehrere Jahre lang funktionieren soll.


0

Nur um die Sache zu verwirren, ist der shBefehl manchmal nur eine symbolische Verknüpfung zu einem anderen Shell-Programm wie ash, bashoder dash.

Ubuntu verwendet, um es zu verknüpfen bash, da bashentwickelt wurde, um alle kompatiblen Bourne-Shell-Skripte auszuführen.

In letzter Zeit hat Ubuntu jedoch auf den shLink zu umgestellt dash. dashwurde entwickelt, um bashSkripte (und damit auch shSkripte) auszuführen , wurde jedoch entwickelt, um nur für Skripte verwendet zu werden, weshalb die interaktiven Funktionen von fehlen bash. Das macht es kleiner und (vielleicht) schneller.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.