Was bedeutet "esac" am Ende einer Bash-Case-Anweisung? Ist es erforderlich?

Ich habe mehrere Beispiele für "esac" gefunden, die am Ende einer Bash-Case-Anweisung erscheinen, aber ich habe keine eindeutige Dokumentation zu ihrer Verwendung gefunden. Die Manpage verwendet es und hat sogar einen Index für das Wort ( https://www.gnu.org/software/bash/manual/bashref.html#index-esac ), definiert aber nicht seine Verwendung. Ist dies der erforderliche Weg, um eine Fallbeschreibung, eine bewährte Vorgehensweise oder eine reine Technik zu beenden?

Wie fifür ifund donefür for, esacist der erforderliche Weg, um eine caseAussage zu beenden .

esacist caserückwärts buchstabiert, eher wie fiist ifrückwärts buchstabiert. Ich weiß nicht, warum das Token, das einen forBlock beendet, nicht ist rof.

Das esacSchlüsselwort ist in der Tat ein erforderliches Trennzeichen, um eine caseAnweisung zu beenden, bashund die meisten unter Unix / Linux verwendeten Shells mit Ausnahme der cshFamilie.

Die ursprüngliche Bourne-Shell wurde von Steve Bourne erstellt, der zuvor an ALGOL68 gearbeitet hatte . Diese Sprache erfand diese umgekehrte Worttechnik, um Blöcke abzugrenzen.

case/esac

if/fi

do/od

Letzteres gibt es do/odnur do/donein Bourne und allen abgeleiteten Shells, auch bashweil odes seit seiner Einführung ( o ctal d ump ) bereits als Unix-Befehl existierte .

Beachten Sie, dass do/doneFunktionsblöcke entweder durch die for, die whileoder die untilAnweisungen eingeführt werden. for, whileUnd untilmüssen nicht beendet werden als doneausreichend ist. Das ist der Grund, warum das Hypothetische rofund die elihwToken nicht benötigt werden .

Das " esac" beendet ein früheres " case", um einen " Codeblock " zu bilden.

In Algol68 werden sie verwendet, im Allgemeinen wird die umgekehrte Zeichenfolge des einleitenden Schlüsselworts zum Beenden des Gehäuses verwendet, z ( if ~ then ~ else ~ fi, case ~ in ~ out ~ esac, for ~ while ~ do ~ od ).

Ich würde sie nach Edsger Dijkstra und seiner Guarded Command Language "Guarded Blocks" nennen .

odWurde in der Bourne-Shell vermutlich nicht verwendet, da der Unix- Befehl "od" bereits vorhanden war .

Die Geschichte:

Die Idee "Guarded Block" scheint von ALGOL 68 zu stammen, zB Englisch:

proc days in month = (int year, month)int:

  case month in
    31,
    if year mod 4=0 ∧ year mod 100≠0  ∨  year mod 400=0 then 29 else 28 fi,
    31, 30, 31, 30, 31, 31, 30, 31, 30, 31
  esac;

Die Algol68-LGU-Implementierung des Sowjets hat das Gleiche getan: In Englisch lautet die ehrfurchtsvolle Erklärung von Algol68 case ~ in ~ out ~ esac, in Kyrillisch lautet sie выб ~ в ~ либо ~ быв.

1975 wurden die Code-Blöcke von Algol68 von Edsger Dijkstra für seine Guarded Command Language ausgeliehen . z.B

if a ≥ b → max := a
| b ≥ a → max := b
fi

Vermutlich verwendete Dijstra "Guarded Blocks", um die in Algol60 implementierte und dann in der Programmiersprache C überarbeitete Dangling else- Ambiguität zu überwinden . (vgl. Schichtreduzierungskonflikt. )

Schließlich - von Algol68 - " esac" schaffte es 1977 mit freundlicher Genehmigung von Stephen R. Bourne , der einen frühen Algol68-Compiler namens ALGOL 68C entwickelt hatte, in die Bourne-Shell (wo Sie es entdeckten esac) .

Bekanntermaßen verwendete Stephen diese Guarded Blocks auch in einer "C-Header-Datei" namens " macro.h"

#define IF  if(
#define THEN    ){
#define ELSE    } else {
#define ELIF    } else if (
#define FI  ;}

Die bemerkenswerten Software-Genies Landon Curt Noll und Larry Bassel stießen 1984 bei der Genix-Portierungsgruppe von National Semiconductor auf Steves macro.h-Code und hatten Mühe, dessen Anwendung zu verstehen. Und so gründete Landon & Larry den International Obfuscated C Code Contest ...

Von 1984 bis heute gab es mehrere tausend andere "bessere" Programmiersprachen, die die geschützten Befehle von Dijkstra nicht verwenden. Und Steven Bournes Einsatz in diesen macro.hStudiengängen wird inzwischen häufig in den "Software Development Dissertations" von IT-Studenten als Beweis dafür angeführt, dass sie nicht in Vorlesungen geschlafen haben. :-)

Ja, das ist erforderlich. Wie Jacob oben ausgeführt hat, ist die Logik dieselbe wie bei if/ fi. Herkömmliche C-Kommentar-Begrenzer /*und werden */ähnlich gepaart. Da C so geschrieben wurde, dass Unix größtenteils in C mit einem Minimum an Assembler-Code und einer großen Überlappung zwischen den C- und Unix-Entwicklungsteams geschrieben werden kann, ist es vernünftig, eine gemeinsame Quelle des Begriffs anzunehmen, dass das abschließende Äquivalent eines Multi -Zeichenblock-Begrenzer sollte dieselbe Zeichenfolge in umgekehrter Reihenfolge sein.

Im Gegensatz dazu Schleifen wie for, whileund untilVerwendung do... donestattdessen Charakter , um umzukehren, so gibt es einige Inkonsistenz.