Was bedeutet es, „sh-kompatibel“ zu sein?

Ich habe den Ausdruck "sh-kompatibel" gesehen, der normalerweise in Bezug auf Muscheln verwendet wird. Ich bin mir nicht sicher, ob dies auch für die Programme gilt, die möglicherweise aus Shells heraus ausgeführt werden.

Was bedeutet es für eine Shell oder ein anderes Programm, "sh-kompatibel" zu sein? Was würde es bedeuten, "sh inkompatibel" zu sein?

Bearbeiten: Diese Frage nach dem Unterschied zwischen Bash und Sh ist sehr relevant: Unterschied zwischen Sh und Bash

Ich hätte immer noch gerne eine direkte Antwort darauf, was es heißt, "sh-kompatibel" zu sein. Eine vernünftige Erwartung könnte sein, dass "sh-kompatibel" bedeutet, dass "die Shell-Befehlssprache implementiert". Warum gibt es dann so viele "sh-kompatible" Shells und warum unterscheiden sie sich?

Warum gibt es so viele "sh-kompatible" Shells?

Die Bourne-Shell wurde erstmals 1979 als Teil von Unix V7 veröffentlicht . Da so ziemlich jedes Unix- und Unix-ähnliche System von V7-Unix abstammt - wenn auch nur geistig - ist die Bourne-Shell "für immer" bei uns

Die Bourne-Shell ersetzte tatsächlich eine frühere Shell, die Thompson-Shell genannt wurde , aber dies geschah so früh in der Geschichte von Unix, dass es heute so gut wie vergessen ist. Die Bourne-Shell ist eine Obermenge der Thompson-Shell .²

Sowohl die Bourne- als auch die Thompson-Granate wurden aufgerufen sh. Die von POSIX angegebene Shell wird auch aufgerufen sh. Wenn also jemand sagt sh, dass er mit -kompatibel ist, bezieht er sich mit der Handbewegung auf diese Reihe von Muscheln. Wenn sie spezifisch sein wollten, sagten sie "POSIX-Shell" oder "Bourne-Shell". ³

Die POSIX-Shell basiert auf der 1988er Version von KornShell , die wiederum die Bourne-Shell unter AT & T Unix ersetzen sollte und die BSD-C-Shell in Bezug auf die Funktionen kshüberholte Unix- und Unix-ähnliche Systeme enthalten heute einige Varianten der Korn-Shell. Ausnahmen sind in der Regel winzige eingebettete Systeme, die sich den Platz nicht leisten können, den eine vollständige POSIX-Shell einnimmt.

Allerdings wurde die Korn-Shell - im Gegensatz zur POSIX-Shell - außerhalb der kommerziellen Unix-Welt nie wirklich populär. Dies liegt daran, dass sein Aufstieg mit den Anfangsjahren der Unix-Kommerzialisierung korrespondierte und er sich in den Unix-Kriegen verfing . BSD Unixes hat es zugunsten der C-Shell vermieden, und sein Quellcode war zu Beginn nicht frei für Linux verfügbar. Als die frühen Linux-Distributoren nach einer Befehls-Shell suchten, die zu ihrem Linux-Kernel passte, suchten sie Normalerweise haben sie sich für GNU Bash entschieden , eine der shKompatiblen , von denen Sie sprechen. «

Die frühe Verbindung zwischen Linux und Bash so ziemlich das Schicksal vielen anderen Schalen versiegelt, einschließlich ksh, cshund tcsh. Es gibt heute immer noch Hardcore-Spieler, die diese Muscheln verwenden, aber sie sind in der Minderheit. «

All diese Geschichte erklärt , warum die Schöpfer der relativen Nachzügler wie bash, zshund yashwählen , um sie sh-kompatible: Bourne / POSIX - Kompatibilität das Minimum ist eine Shell für Unix-ähnliche Systeme bereitstellen , um muß weit verbreitete Annahme zu gewinnen.

In vielen Systemen ist die interaktive Standard-Befehls-Shell und /bin/shgibt verschiedene Dinge. /bin/shvielleicht:

• Die ursprüngliche Bourne-Shell. Dies ist in älteren UNIX®-Systemen wie Solaris 10 (herausgegeben im Jahr 2005) und seinen Vorgängern üblich

• Eine POSIX-zertifizierte Shell. Dies ist in neueren UNIX®-Systemen wie Solaris 11 (2010) üblich.

• Die Almquist-Muschel . Dies ist ein Open-Source-Bourne / POSIX-Shell-Klon, der ursprünglich 1989 im Usenet veröffentlicht wurde und dann zur Aufnahme in Berkeleys CSRG in die erste BSD-Version ohne AT & T-Quellcode, 4.4BSD-Lite , beigetragen wurde . Die Almquist-Shell wird oft genannt ash, auch wenn sie als installiert ist /bin/sh.

  4.4BSD-Lite wurde wiederum zur Basis für alle modernen BSD-Derivate, wobei die /bin/shmeisten davon als Almquist-Derivat verblieben sind, mit einer wichtigen Ausnahme, die unten aufgeführt ist. Sie können diese direkte Nachkommenschaft in den Quellcode-Repositories für NetBSD und FreeBSD sehen : Sie haben ab Tag 1 ein Almquist-Shell-Derivat ausgeliefert.

  Es gibt zwei wichtige ashGabeln außerhalb der BSD-Welt:

  1. dash, 2006 von Debian und Ubuntu als Standardimplementierung übernommen /bin/sh. (Bash bleibt die standardmäßige interaktive Befehlsshell in Debian-Derivaten.)

  2. Der ashBefehl in BusyBox , der häufig in eingebetteten Linuxen verwendet wird und für die Implementierung verwendet werden kann /bin/sh. Da es nach dem Datum veröffentlicht wurde dashund von Debians altem ashPaket abgeleitet wurde , habe ich mich dafür entschieden, es trotz seines Befehlsnamens in BusyBox als Ableitung von dashanstatt zu betrachten ash.

     (BusyBox enthält auch eine weniger featureful Alternative zu ashgenannt hush. In der Regel nur eine der beiden wird in gebaut werden jedes gegebene BusyBox binär: ashstandardmäßig, aber hush. , Wenn der Platz wirklich dicht ist somit /bin/shauf BusyBox-basierten Systemen ist nicht immer dash. -Ähnlichen)

• GNU Bash , das die meisten seiner Nicht-POSIX-Erweiterungen deaktiviert, wenn es als aufgerufen wirdsh .

  Diese Wahl ist typisch für Desktop- und Servervarianten von Linux, mit Ausnahme von Debian und seinen Derivaten. Dies hat auch Mac OS X seit Panther getan, das 2003 veröffentlicht wurde.

• Eine Schale mit ksh93POSIX - Erweiterungen , wie in OpenBSD . Obwohl die OpenBSD-Shell das Verhalten ändert, um Syntax- und semantische Inkompatibilitäten mit Bourne- und POSIX-Shells zu vermeiden, wenn sie als aufgerufen wird sh, deaktiviert sie keine ihrer reinen Erweiterungen, da diese nicht mit älteren Shells in Konflikt stehen.

  Dies ist nicht üblich; Sie sollten keine ksh93Features in erwarten /bin/sh.

Ich habe "Shell-Skript" oben als Oberbegriff für Bourne / POSIX-Shell-Skript verwendet. Dies ist auf die Allgegenwart der Bourne-Familie zurückzuführen. Um über Skripte in anderen Shells zu sprechen, müssen Sie ein Qualifikationsmerkmal wie "C-Shell-Skript" angeben. Selbst auf Systemen, auf denen eine Shell der C-Familie die standardmäßige interaktive Shell ist, ist es besser , die Bourne-Shell für die Skripterstellung zu verwenden.

Es ist bezeichnend, dass Wikipedia Unix-Shells klassifiziert und in Bourne-Shell-kompatible, C-Shell-kompatible und "andere" gruppiert.

Dieses Diagramm kann helfen:

(Klicken Sie für die SVG-Version, 31 kB, oder zeigen Sie die PNG-Version in voller Größe an , 218 kB.)

Was würde es bedeuten, "sh inkompatibel" zu sein?

Jemand, der von einer shinkompatiblen Sache spricht, hat normalerweise eine der folgenden drei Bedeutungen:

1. Sie beziehen sich auf eine dieser "anderen" Muscheln. «

2. Sie unterscheiden zwischen den Bourne- und C-Shell-Familien.

3. Sie sprechen über eine bestimmte Funktion in einer Shell der Bourne-Familie, die nicht in allen anderen Shells der Bourne-Familie enthalten ist. ksh93,, bashund zshhaben insbesondere viele Funktionen, die in den älteren "Standard" -Shells nicht vorhanden sind. Diese drei sind auch in vielerlei Hinsicht inkompatibel, sobald Sie über das gemeinsam genutzte POSIX / die ksh88Basis hinausgehen .

Es ist ein klassischer Fehler, ein Shell-Skript mit einer #!/bin/sh Shebang-Zeile oben zu schreiben, aber Bash- oder Korn-Shell-Erweiterungen zu verwenden. Da /bin/shes sich heutzutage auf so vielen Systemen um eine der Shells im obigen Diagramm der Korn / POSIX-Familie handelt, funktionieren solche Skripte auf dem System, auf dem sie geschrieben wurden, aber auf Systemen, auf denen /bin/shsich etwas aus der breiteren Bourne-Familie von Shells befindet, nicht. Es wird empfohlen, Zeilen zu verwenden #!/bin/bashoder zu #!/bin/kshverknüpfen, wenn das Skript solche Erweiterungen verwendet.

Es gibt viele Möglichkeiten, um zu überprüfen, ob ein bestimmtes Shell-Skript der Bourne-Familie portierbar ist:

• Führen Sie checkbashismses aus, ein Tool aus dem Debian-Projekt, das ein Skript auf " Bashismen " überprüft .

• Führen Sie es unter posheiner Shell im Debian-Paket-Repository aus, die absichtlich nur von SUS3 spezifizierte Funktionen sowie einige andere kleinere Funktionen implementiert .

• Führen Sie es oshaus dem Schily Tools-Projekt aus , einer verbesserten Version der Bourne-Shell, die 2005 von Sun als Teil von OpenSolaris als Open-Source-Version bereitgestellt wurde. Dies macht es zu einer der einfachsten Möglichkeiten, eine Bourne-Shell im Stil von 1979 auf einem modernen Computer zu installieren.

  Die Schily Tools-Distribution enthält boshauch eine POSIX-Shell mit vielen nicht standardmäßigen Funktionen , die jedoch nützlich sein kann, um die Kompatibilität von Shell-Skripten zu testen, die auf allen Shells der POSIX-Familie ausgeführt werden sollen. Es neigt dazu , in seiner Funktion konservativer zu sein als gesetzt bash, zshund die erweiterten Versionen ksh93.

  Schily Tools enthält auch eine so genannte Shell bsh, aber das ist eine historische Kuriosität, die überhaupt keine Shell der Bourne-Familie ist.

• Lesen Sie das Kapitel Portable Shell Programming im GNU Autoconf-Handbuch . Möglicherweise kennen Sie einige der problematischen Konstrukte in Ihren Skripten.

Warum unterscheiden sie sich?

Aus den gleichen Gründen alle "Neu & Verbessert!" Dinge sind anders:

• Die verbesserte Version konnte nur durch Aufheben der Abwärtskompatibilität verbessert werden.

• Jemand dachte an eine andere Arbeitsweise, die er besser mag, die aber nicht die gleiche ist wie die alte.

• Jemand hat versucht, einen alten Standard neu zu implementieren, ohne ihn vollständig zu verstehen, also haben sie Fehler gemacht und einen unbeabsichtigten Unterschied geschaffen.

Fußnoten und Nebenbemerkungen :

1. Frühere Versionen von BSD Unix waren nur Add-On-Software-Sammlungen für V6 Unix. Da die Bourne-Shell erst in V7 zu AT & T Unix hinzugefügt wurde, hatte BSD die Bourne-Shell technisch gesehen nicht in den Anfängen. Die Antwort von BSD auf die primitive Natur der Thompson-Schale war die C-Schale .

   Die ersten eigenständigen Versionen von BSD (2.9BSD und 3BSD) basierten jedoch auf V7 oder dessen portablem Nachfolger UNIX / 32V und enthielten daher die Bourne-Shell.

   (Die 2BSD Linie verwandelte sich in eine parallele Gabel von BSD für Digital PDP Minicomputer , während die 3BSD und 4BSD Linien ging um die neueren Computertypen wie zu nehmen VAXen und Unix - Workstations 2.9BSD war im Wesentlichen die PDP - Version von 4.1cBSD;. Sie waren zeitigen und gemeinsamer Code . PDPs nicht nur verschwinden , wenn der VAX angekommen, so dass die 2BSD Linie ist noch shambling entlang .)

   Man kann mit Sicherheit sagen, dass die Bourne-Shell 1983 überall in der Unix-Welt war. Das ist eine gute Annäherung an "für immer" in der Computerbranche. MS-DOS bekam ein hierarchisches Dateisystem , das Jahr (awww, wie cuuute!) Und der erste 24-Bit - Macintosh mit seinem 9" B & W - Bildschirm - nicht Graustufen, buchstäblich schwarz und weiß - würde früh im nächsten Jahr nicht kommen , bis.

2. Die Thompson-Schale war für heutige Verhältnisse recht primitiv . Es war nur eine interaktive Befehls-Shell und nicht die Skript-Programmierumgebung, die wir heute erwarten. Es gab Dinge wie Pipes und E / A-Umleitung, die wir als prototypischen Teil einer "Unix-Shell" betrachten, so dass wir uns die MS-DOS-Befehlsshell als von Unix erhalten vorstellen.

   Die Bourne - Shell ersetzt auch die PWB Schale , die wichtige Dinge auf die Thompson Shell wie Programmierbarkeit (hinzugefügt if, switchund while) und eine frühe Form von Umgebungsvariablen. Die PWB-Shell ist noch weniger bekannt als die Thompson-Shell, da sie nicht in jeder Unix-Version enthalten war.

3. Wenn jemand nicht speziell auf die Kompatibilität von POSIX und Bourne-Shell eingeht, kann dies eine ganze Reihe von Dingen bedeuten.

   In einem Extremfall könnten sie die Bourne-Shell von 1979 als Basis verwenden. Ein „ sh-kompatiblen Skript“ in diesem Sinne würde bedeuten , es wird erwartet, perfekt auf die wahre Bourne - Shell oder einem seiner Nachfolger und Klone laufen: ash, bash, ksh, zsh, usw.

   Jemand im anderen Extrem nimmt stattdessen die von POSIX als Basis angegebene Shell an. Wir nehmen heutzutage so viele POSIX-Shell-Funktionen als "Standard", dass wir oft vergessen, dass sie in der Bourne-Shell nicht vorhanden waren: integrierte Arithmetik, Auftragssteuerung, Befehlsverlauf, Aliase, Befehlszeilenbearbeitung, $()Befehlsform Substitution usw.

4. Obwohl die Korn-Shell Wurzeln hat, die bis in die frühen 1980er Jahre zurückreichen, wurde sie von AT & T erst 1988 in System V Release 4 unterksh Unix ausgeliefert Ende der 1980er Jahre.

   (Ein paar seltsame Unix-Aromen, die auf SVR3 basierten und sich vor der Veröffentlichung von SVR4 auf dem Markt behaupteten, waren jedoch die ersten, als die Revolution kam.)

   1988 ist auch das Jahr, in dem der erste POSIX-Standard mit seiner auf der Korn-Shell basierenden "POSIX-Shell" herauskam. Später, 1993, erschien eine verbesserte Version der Korn-Shell. Da POSIX das Original an Ort und Stelle effektiv genagelt, kshgegabelt in zwei Hauptversionen: ksh88und ksh93, benannt nach den in ihrer Spaltung beteiligt Jahren.

   ksh88ist nicht vollständig POSIX-kompatibel, obwohl die Unterschiede gering sind, so dass einige Versionen der ksh88Shell als POSIX-kompatibel gepatcht wurden. (Dies ist ein interessantes Interview über Slashdot mit Dr. David G. Korn . Ja, der Typ, der die Shell geschrieben hat.)

   ksh93ist eine voll kompatible Obermenge der POSIX-Shell . Die Entwicklung von ksh93wurde sporadisch fortgesetzt, seit das primäre Quell-Repository von AT & T auf GitHub verschoben wurde. Die neueste Version ist ungefähr 3 Jahre alt, als ich dies schreibe, ksh93v. (Der Basisname des Projekts bleibt ksh93mit Suffixen versehen, um Release-Versionen nach 1993 zu kennzeichnen.)

   Systeme, die eine Korn-Shell separat von der POSIX-Shell enthalten, stellen diese normalerweise zur Verfügung /bin/ksh, obwohl sie sich manchmal an anderer Stelle versteckt.

   Wenn wir über kshdie Korn-Shell oder über deren Namen sprechen, sprechen wir über ksh93Funktionen, die sie von ihren abwärtskompatiblen Bourne- und POSIX-Shell-Teilmengen unterscheiden. Du rennst ksh88heute selten über das Reine .

5. AT & T hat den Quellcode der Korn-Shell bis März 2000 geschützt . Zu diesem Zeitpunkt war Linux sehr stark mit GNU Bash verbunden. Bash und ksh93 beide haben Vorteile gegenüber den anderen , aber an diesem Punkt hält die Trägheit Linux eng mit Bash verbunden.

   Wie, warum über die frühen Linux - Anbieter am häufigsten wählen GNU Bash pdksh, das war zu der Zeit verfügbaren Linux wurde getting started, würde ich denke , es ist , weil so viel von dem Rest des Userland auch herkam dem GNU - Projekt . Bash ist auch etwas fortgeschrittener als pdksh, da sich die Bash-Entwickler nicht darauf beschränken, Korn-Shell-Features zu kopieren.

   pdkshUngefähr zu dem Zeitpunkt, als AT & T den Quellcode für die echte Korn-Shell freigegeben hat, wurden die Arbeiten eingestellt. Es gibt jedoch zwei Hauptgabeln , die noch gewartet werden: die OpenBSD - pdkshund die MirBSD - Korn - Shellmksh .

   Ich finde es interessant, dass dies mkshdie einzige Korn-Shell-Implementierung ist, die derzeit für Cygwin gepackt ist.

6. GNU Bash geht in vielerlei Hinsicht über POSIX hinaus, aber Sie können es bitten, in einem reineren POSIX-Modus zu laufen .

7. csh/ tcshwar bis Anfang der 90er Jahre normalerweise die standardmäßige interaktive Shell unter BSD Unixes.

   Als BSD-Variante waren frühe Versionen von Mac OS X über Mac OS X 10.2 "Jaguar" auf diese Weise verfügbar . OS X hat die Standard-Shell tcshin OS X 10.3 "Panther" von auf Bash umgestellt . Diese Änderung hatte keine Auswirkungen auf Systeme, die von 10.2 oder früher aktualisiert wurden. Die vorhandenen Benutzer auf diesen konvertierten Systemen behielten ihre tcshShell.

   FreeBSD behauptet, weiterhin tcshals Standard-Shell verwendet zu werden , aber auf der FreeBSD 10-VM, die ich hier habe, scheint die Standard-Shell eine der POSIX-kompatiblen Almquist-Shell-Varianten zu sein . Dies gilt auch für NetBSD.

   OpenBSD verwendet pdkshstattdessen einen Fork als Standard-Shell.

   Die höhere Popularität von Linux und OS X lässt manche Menschen wünschen, dass FreeBSD auch zu Bash wechseln würde, aber aus philosophischen Gründen werden sie dies in Kürze nicht tun . Es ist leicht zu wechseln , wenn Sie das stört.

8. Heutzutage ist es selten, ein System mit einer echten Vanille-Bourne-Shell zu finden /bin/sh. Sie müssen sich sehr viel Mühe geben, um etwas zu finden, das für Kompatibilitätstests ausreicht.

   Mir ist nur eine Möglichkeit bekannt, eine echte Bourne-Shell aus dem Jahr 1979 auf einem modernen Computer auszuführen: Verwenden Sie die Ancient Unix V7- Datenträgerabbilder mit dem SIMH PDP-11-Simulator aus dem Computer History Simulation Project . SIMH läuft auf so ziemlich jedem modernen Computer , nicht nur auf Unix-ähnlichen Computern . SIMH läuft sogar auf Android und iOS .

   Mit OpenSolaris hat Sun zum ersten Mal die SVR4-Version der Bourne-Shell als Open-Source-Version bereitgestellt. Zuvor war der Quellcode für die Post-V7-Versionen der Bourne-Shell nur für Benutzer mit einer Unix-Quellcodelizenz verfügbar.

   Dieser Code ist jetzt separat vom Rest des nicht mehr existierenden OpenSolaris-Projekts aus verschiedenen Quellen verfügbar.

   Die direkteste Quelle ist das Heirloom Bourne-Shell-Projekt . Dies wurde kurz nach der ursprünglichen Veröffentlichung von OpenSolaris im Jahr 2005 verfügbar. In den nächsten Monaten wurden einige Portabilitäts- und Fehlerbehebungsarbeiten durchgeführt, die Entwicklung des Projekts wurde jedoch gestoppt.

   Jörg Schilling hat eine Version dieses Codes besser gepflegt als oshsein Schily Tools- Paket. Mehr dazu siehe oben.

   Beachten Sie, dass diese Shells, die aus der Quellcodeversion 2005 stammen , Unterstützung für Multibyte-Zeichensätze , Auftragssteuerung, Shell-Funktionen und andere Funktionen enthalten, die in der ursprünglichen Bourne-Shell von 1979 nicht enthalten sind.

   Eine Möglichkeit, festzustellen, ob Sie sich in einer Original-Bourne-Shell befinden, besteht darin, zu prüfen, ob diese eine undokumentierte Funktion unterstützt, die hinzugefügt wurde, um den Übergang von der Thompson-Shell zu erleichtern: ^als Alias ​​für |. Das heißt, ein Befehl wie ls ^ moregibt einen Fehler in einer Korn- oder POSIX-Shell aus, aber er verhält sich wie ls | morein einer echten Bourne-Shell.

9. Gelegentlich trifft man auf einen fish, scshoder rc/eshaftend, aber sie sind noch seltener als C - Shell - Fans.

   Die rcFamilie der Shells wird auf Unix- / Linux-Systemen normalerweise nicht verwendet, aber die Familie ist historisch wichtig. So hat sie sich einen Platz im obigen Diagramm verdient. rcist die Standard-Shell des Betriebssystems Plan 9 von Bell Labs , eine Art Nachfolger von Unix der 10. Edition , die im Rahmen der fortgesetzten Forschung von Bell Labs im Bereich Betriebssystemdesign entwickelt wurde. Es ist auf Programmierebene nicht mit der Bourne- und der C-Shell kompatibel. Da ist wahrscheinlich eine Lektion drin.

   Die aktivste Variante von rcscheint die von Toby Goodwin gepflegte zu sein , die auf dem Unix- rcKlon von Byron Rakitzis basiert.

"sh compatible" bezieht sich auf POSIXsh , die Basis-Shell, die auf allen kompatiblen Systemen vorhanden sein muss. Ein sh-kompatibles Skript sollte auf jedem POSIX-kompatiblen Computer funktionieren.

Der Grund, warum es notwendig ist, dies zu sagen, ist, dass es sich in der Regel /bin/shum einen Symlink zu handelt /bin/bash, der einige Bashisms in Skripten verwandelt, die sich selbst für die Verwendung shmit deklarieren #!/bin/sh. Diese Skripte funktionieren nicht auf Systemen, die nicht bashals solche verwendet werden /bin/sh, einschließlich einiger kommerzieller Unices für immer, sowie Debian und Derivaten in letzter Zeit.

Insbesondere gab es in letzter Zeit einen Trend dash, die Debian-Almquish-Shell als Standard zu verwenden sh, da sie kleiner ist und schneller sein soll. Dieser Trend hat viele dieser Bashisms hervorgehoben, die in angeblichen shSkripten vorkamen . Wenn Sie etwas als "sh-kompatibel" bezeichnen, bedeutet dies, dass ausdrücklich beabsichtigt ist, mit diesen Systemen zu arbeiten, indem die von POSIX festgelegte Sprache vollständig eingehalten wird. Alle Shells implementieren eine Obermenge dieser Funktionalität, sodass sie garantiert überall funktionieren, ihre Erweiterungen jedoch nicht miteinander kompatibel.

Verschiedene Shells haben ihre eigenen Entwicklungsverläufe und unterscheiden sich im Laufe der Zeit in verschiedene Richtungen, da sie Funktionen zur interaktiven Verwendung für ihre Benutzer oder Skripterweiterungen wie assoziative Arrays hinzugefügt haben. Ein "sh-inkompatibles" Skript würde einige dieser nicht standardmäßigen Erweiterungsfunktionen verwenden, z. B. Bashs [[Bedingungen.

Die Nicht-POSIX-Funktionen in bashund tcshund zshallen anderen aktuellen Shells sind nützlich , und es gibt viele Gelegenheiten, in denen Sie sie benötigen oder wollen. Sie sollten nur nicht in einem Skript verwendet werden, mit dem sich die Arbeit anmeldet /bin/sh, da Sie sich nicht darauf verlassen können, dass sich diese Funktionen in der Basisimplementierung shdes Systems befinden, auf dem Sie ausgeführt werden.

Ein Skript, das beispielsweise assoziative Arrays verwenden muss, sollte sicherstellen, dass es ausgeführt wird, bashund nicht sh:

#!/bin/bash
declare -A array

Das funktioniert überall mit bash. Skripte, die die erweiterte Funktionalität nicht benötigen und portabel sein sollen, sollten deklarieren, dass sie shdie Basisshell-Befehlssprache verwenden und sich an diese halten.