Shebang (Unix)

#!
Shebang

Im Computer, a Shebang ist die Zeichensequenz, die aus den Zeichen besteht Nummernschild und Ausrufezeichen (#!) zu Beginn von a Skript. Es heißt auch Scharfe Exklamation, Sha-Bang,[1][2] Hashbang,[3][4] Pfund-Bang,[5][6] oder Hash-Pling.[7]

Wenn eine Textdatei mit einem Shebang verwendet wird, als ob sie eine ausführbare Datei in a Unix-artig Betriebssystem, die Programmlader Mechanismus analysiert den Rest der Ausgangszeile der Datei als Interpreter -Richtlinie. Der Lader führt den angegebenen aus Dolmetscher Programm, das als Argument unter Verwendung des Pfades übergeben wurde, der ursprünglich beim Versuch, das Skript auszuführen, verwendet wurde, damit das Programm die Datei als Eingabedaten verwendet.[8] Zum Beispiel, wenn ein Skript mit dem Pfad benannt wird Pfad/zu/Skriptund es beginnt mit der folgenden Zeile, #!/bin/shdann wird der Programmlader angewiesen, das Programm auszuführen /bin/sh, Vorbeigehen Pfad/zu/Skript als erstes Argument. Im LinuxDieses Verhalten ist das Ergebnis sowohl des Kernel- als auch des Benutzer-Raum-Codes.[9]

Die Shebang -Linie wird normalerweise vom Dolmetscher ignoriert, weil der "#" Charakter a ist Kommentar Marker in vielen Skriptsprachen; Einige Sprachdolmetscher, die die Hash -Marke nicht verwenden, um Kommentare zu beginnen, können die Shebang -Linie immer noch ignorieren, um ihren Zweck zu erkennen.[10]

Syntax

Die Form eines Schäfers Interpreter -Richtlinie ist wie folgt:[8]

#!Dolmetscher [Optional-Arg] 

in welchem Dolmetscher ist im Allgemeinen ein absoluter Pfad zu einem ausführbaren Programm. Das optionale Argument ist eine Zeichenfolge, die ein einzelnes Argument darstellt. Weißer Raum danach #! es ist optional.

Im Linux, die Datei angegeben von Dolmetscher kann ausgeführt werden, wenn es eines der folgenden hat:

  • Der richtige Ausführen und Code enthält Code, den der Kernel direkt ausführen kann,
  • eine dafür definierte Wrapper durch sysctl (wie für die Ausführung von Microsoft .exe Binärdateien verwenden Wein),
  • ein Schebang.

Auf Linux und MinixEin Dolmetscher kann auch ein Skript sein. Eine Kette von Shebangs und Wrappern liefert eine direkt ausführbare Datei, mit der die angetroffenen Skripte als Parameter in umgekehrter Reihenfolge erhalten werden. Zum Beispiel wenn Datei /bin/a ist eine ausführbare Datei in ELF Format, Datei /bin/b Enthält den Shebang #!/bin/A optparam, und Datei /bin/c Enthält den Shebang #!/bin/Bdann die Datei ausführen /bin/c beschließt /bin/B /bin/C, was sich schließlich entschlossen /bin/A optparam /bin/B /bin/C.

Im Solaris- und Darwin-Abgeleitete Betriebssysteme (wie z. Mac OS), die von angegebene Datei von Dolmetscher Muss ein ausführbarer binär sein und kann selbst kein Skript sein.[11]

Beispiele

Einige typische Shebang -Linien:

  • #!/bin/sh - Führen Sie die Datei mit dem aus Bourne Shell, oder eine kompatible Hülle, von denen angenommen wird, dass sie sich im /Bin -Verzeichnis befindet
  • #!/bin/bash - Führen Sie die Datei mit dem aus Bash Shell
  • #!/usr/bin/pwsh - Führen Sie die Datei mit Power Shell
  • #!/usr/bin/env python3 - mit einem ausführen Python Interpreter mit der env Programmsuchpfad, um es zu finden
  • #!/bin/false -nichts tun, aber zurückbleiben Sie einen ungleich Null zurück Status beenden, Anzeichen für ein Versagen. Wird verwendet, um eine eigenständige Ausführung einer Skriptdatei zu verhindern, die für die Ausführung in einem bestimmten Kontext bestimmt ist, wie beispielsweise von der . Befehl von sh/bash, Quelle von CSH/TCSH oder als .profile, .cshrc oder .login -Datei.

Shebang -Linien können spezifische Optionen enthalten, die an den Dolmetscher übergeben werden. Implementierungen variieren jedoch im Parsenverhalten von Optionen. Für die Portabilität sollte nur eine Option ohne eingebettete Whitespace angegeben werden. Weitere Portabilitätsrichtlinien finden Sie nachstehend.

Zweck

Mit Interpreter -Direktiven können Skripte und Datendateien als Befehle verwendet werden, wodurch die Details ihrer Implementierung vor Benutzern und anderen Programmen versteckt werden, indem die Notwendigkeit entfernt werden muss, Skripte mit ihrem Interpreter in der Befehlszeile zu präfixen.

A Bourne Shell Skript, das durch den Pfad identifiziert wird Einige/Pfad/to/foo, hat die Anfangsgrenze,

#!/bin/sh -x

und wird mit Parametern ausgeführt Bar und Baz wie

Einige/Pfad/to/foo Bar Baz

Bietet ein ähnliches Ergebnis wie stattdessen die folgende Befehlszeile ausgeführt hat:

/bin/sh -x einige/Pfad/to/foo Bar Baz

Wenn /bin/sh Gibt die an Bourne Shellund dann ist das Endergebnis, dass alle Shell -Befehle in der Datei Einige/Pfad/to/foo werden mit den Positionsvariablen ausgeführt $ 1 und $ 2 die Werte haben Bar und Baz, beziehungsweise. Auch, weil die Anfang Nummernschild ist der Charakter, mit dem Kommentare in die eingeführt werden? Bourne Shell Sprache (und in den Sprachen, die viele andere Dolmetscher verstanden haben), wird die gesamte Shebang -Linie vom Dolmetscher ignoriert.

Es liegt jedoch an dem Dolmetscher, die Shebang -Linie zu ignorieren. Ein Skript, das aus den folgenden zwei Zeilen besteht beide Linien zu Standardausgabe Beim Lauf:

#!/Bin/Cat Hello World!

Stärken

Im Vergleich zur Verwendung globaler Assoziationslisten zwischen Dateierweiterungen und Interpretationsanwendungen ermöglicht die Methode der Interpreter -Richtlinie die Verwendung von Dolmetschern, die auf globaler Systemebene nicht bekannt sind, und ohne Administratorrechte. Es ermöglicht auch eine spezifische Auswahl von Dolmetschern, ohne die zu überladen Dateiname Erweiterung Namespace (Wenn sich eine Dateierweiterung auf mehr als einen Dateityp bezieht) und ermöglicht, dass die Implementierungssprache eines Skripts geändert wird, ohne die Aufrufsyntax durch andere Programme zu ändern. Invoker des Skripts müssen nicht wissen, was die Implementierungssprache ist, da das Skript selbst für die Verwendung des Interpreters verantwortlich ist.

Portabilität

Programmstandort

Shebangs müssen angeben Absolute Wege (oder Pfade in Bezug auf das aktuelle Arbeitsverzeichnis) zu Systemausführbaren; Dies kann Probleme bei Systemen verursachen, die ein nicht standardmäßiges Dateisystemlayout haben. Selbst wenn Systeme ziemlich Standardpfade aufweisen, ist es durchaus möglich, dass Varianten desselben Betriebssystems unterschiedliche Standorte für den gewünschten Dolmetscher haben. Pythonkönnte zum Beispiel in sein /usr/bin/python3, /usr/local/bin/python3, oder sogar so etwas wie /Home/Benutzername/bin/python3 wenn von einem gewöhnlichen Benutzer installiert.

Ein ähnliches Problem besteht für die POSIX Shell, da Possix nur seinen Namen verlangt hatte Sch, aber keinen Pfad. Ein gemeinsamer Wert ist /bin/sh, aber einige Systeme wie Solaris haben die posix-kompatible Hülle bei /usr/xpg4/bin/sh.[12] In vielen Linux Systeme, /bin/sh ist hart oder symbolischer Link zu /bin/bash, das Bourne wieder Shell (Bash). Verwenden von Bash-spezifischen Syntax, während ein Shebang aufrechterhalten wird, auf das zeigt Sch ist auch nicht tragbar.[13]

Aus diesem Grund ist es manchmal erforderlich, die Shebang -Linie nach dem Kopieren a zu bearbeiten Skript Von einem Computer zum anderen, weil der Pfad, der in das Skript codiert wurde, möglicherweise nicht auf einer neuen Maschine gelten, abhängig von der Konsistenz in der Vergangenheit der Vermittlung des Dolmetschers. Aus diesem Grund und weil Posix Standardisiert keine Pfadnamen, POSIX standardisiert die Funktion nicht.[14] Das GNU Autoconf Tool kann mit dem MacRO AC_SYS_INTINPRETER auf Systemunterstützung testen.[15]

Oft das Programm /usr/bin/env kann verwendet werden, um diese Einschränkung durch Einführung einer Ebene von zu umgehen Indirektion. #! wird gefolgt von /usr/bin/env, gefolgt von dem gewünschten Befehl ohne vollständigen Pfad, wie in diesem Beispiel:

#!/usr/bin/env sh

Dies funktioniert meistens, weil der Weg /usr/bin/env wird üblicherweise für die verwendet env Nützlichkeit, und es ruft den ersten an Sch im Benutzer gefunden $ Path, normalerweise /bin/sh.

Dies hat immer noch einige Tragbarkeitsprobleme mit OpenServer 5.0.6 und Unicos 9.0.2, die nur haben /bin/env und nein /usr/bin/env.

Charakterinterpretation

Ein weiteres Problem der Portabilität ist die Interpretation der Befehlsargumente. Einige Systeme, einschließlich Linux, teilen die Argumente nicht auf.[16] Zum Beispiel beim Ausführen des Skripts mit der ersten Zeile wie,

#!/usr/bin/env python3 -c

Der gesamte Text nach dem ersten Raum wird als ein einziges Argument behandelt, das heißt, python3 -c wird als ein Argument an verabschiedet /usr/bin/env, anstatt zwei Argumente. Cygwin verhält sich auch so.

Komplexe Dolmetschungsaufrufe sind durch die Verwendung eines zusätzlichen Verpackung. FreeBSD 6.0 (2005) stellte a ein -S Option für seine env Als es das Shebang-Reading-Verhalten in Nicht-Spaltungsverhalten änderte. Diese Option sagt env um die Zeichenfolge selbst zu teilen.[17] Die gnu env Nützlichkeit seit CoreUtils 8.30 (2018) enthält auch diese Funktion.[18] Obwohl die Verwendung dieser Option das Tragbarkeitsproblem am Kernel -Ende mit der Aufteilung mindert, fügt dies die Anforderung hinzu, dass dies erforderlich ist env Unterstützt diese spezielle Erweiterung.

Ein weiteres Problem sind Skripte, die a enthalten Kutschenrückkehr Charakter unmittelbar nach der Shebang -Linie, vielleicht aufgrund der Bearbeitung auf einem System, das DOS verwendet Zeilenumbrüche, wie zum Beispiel Microsoft Windows. Einige Systeme interpretieren den Wagenrücklaufcharakter als Teil der Dolmetscher Befehl, was zu einer Fehlermeldung führt.[19]

magische Zahl

Der Shebang ist eigentlich eine menschlich lesbare Instanz von a magische Zahl In der ausführbaren Datei ist die magische Byte -Zeichenfolge 0x23 0x21die Zwei-Charakter-Codierung in ASCII von #!. Diese magische Zahl wird von der "erkannt"Geschäftsführer"Familie von Funktionen, die feststellen, ob eine Datei ein Skript oder ein ausführbarer Binärdatum ist. Das Vorhandensein des Shebang führt zur Ausführung der angegebenen ausführbaren Datei, normalerweise ein Interpret für die Sprache des Skripts. Es wurde behauptet[20] dass einige alte Versionen von Unix erwarten, dass der normale Shebang von einem Raum und einem Schrägstrich gefolgt wird (ein Schrägstrich (#! /), aber das scheint falsch zu sein;[21] Vielmehr wurden Blanks nach dem Shebang traditionell erlaubt und manchmal mit einem Raum dokumentiert (siehe die E -Mail von 1980 in Geschichte Abschnitt unten).

Die Shebang -Charaktere werden durch dieselben zwei Bytes in dargestellt erweiterte ASCII Codierungen, einschließlich UTF-8, die üblicherweise für Skripte und andere Textdateien auf aktuellen UNIX-ähnlichen Systemen verwendet wird. UTF-8-Dateien können jedoch mit dem optionalen beginnen Byte -Bestellmarke (Bom); Wenn die Funktion "Exec" die Bytes spezifisch erkennt 0x23 und 0x21dann die Anwesenheit der Bom (0xef 0xBB 0xBF) Bevor der Shebang den Skriptdolmetscher daran hindert, hingerichtet zu werden. Einige Behörden empfehlen die Verwendung der Byte -Bestellungsmarke in Posix (Unix-ähnliche) Skripte,[22] Aus diesem Grund und aus größerer Interoperabilität und philosophischer Bedenken. Zusätzlich ist in UTF-8 eine Byte-Bestellmarke nicht erforderlich, da diese Codierung nicht hat Endiangess Ausgaben; Es dient nur dazu, die Codierung als UTF-8 zu identifizieren.

Etymologie

Eine ausführbare Datei, die mit einer Interpreter -Anweisung beginnt, wird einfach als Skript bezeichnet, das häufig mit dem Namen oder der allgemeinen Klassifizierung des beabsichtigten Interpreter vorangestellt ist. Der Name Shebang Für die unverwechselbaren zwei Charaktere stammen möglicherweise von einem ungenauen Kontraktion von Scharf Knall oder Hash Bangbezieht sich auf die beiden typischen Unix -Namen für sie. Eine andere Theorie über die Sch in Shebang ist, dass es aus der Standardschale stammt Sch, normalerweise mit Shebang angerufen.[23] Diese Nutzung war bis Dezember 1989 aktuell,[24] und wahrscheinlich früher.

Geschichte

Der Shebang wurde von vorgestellt von Dennis Ritchie zwischen Ausgabe 7 und 8 bei Bell Laboratories. Es wurde auch zu der hinzugefügt BSD Veröffentlichungen von Berkeleys Informatikforschung (anwesend bei 2.8bsd[25] und standardmäßig von 4.2bsd aktiviert). Als AT & T Bell Laboratories Edition 8 UNIX und spätere Ausgaben wurden nicht in die Öffentlichkeit veröffentlicht, war das erste weithin bekannte Auftritt dieses Features auf BSD.

Das Fehlen einer Dolmetscherrichtlinie, aber die Unterstützung von Shell -Skripten ist in der Dokumentation aus erkennbar Version 7 Unix 1979,,[26] Was stattdessen eine Einrichtung der Bourne -Shell beschreibt, in der Dateien mit Ausführungsgenehmigung speziell von der Shell behandelt werden, was (manchmal von den ersten Zeichen im Skript abhängig war, wie ":" oder "#") eine Unterschale hervorbringt und führen Sie die in der Datei enthaltenen Befehle aus. In diesem Modell würden sich Skripte nur als andere Befehle verhalten, wenn sie innerhalb einer Bourne -Shell aufgerufen werden. Ein Versuch, eine solche Datei direkt über das Betriebssystem auszuführen exec () Die Systemfalle würde fehlschlagen und verhindert, dass Skripte sich als normale Systembefehle einheitlich verhalten.

In späteren Versionen von Unix-ähnlichen Systemen wurde diese Inkonsistenz entfernt. Dennis Ritchie eingeführte Kernelunterstützung für Dolmetscheranweisungen im Januar 1980 für Version 8 Unix, mit der folgenden Beschreibung:[25]

Ab dem 10. Januar 01:37:58 1980> von DMR Thu Jan 10 04:25:49 1980 Remote aus der Forschung wurde das System geändert, sodass eine Datei, die ausgeführt wird, mit den magischen Charakteren #beginnt! Der Rest der Zeile wird als Name eines Interpreters für die ausgeführte Datei verstanden. Zuvor (und in der Tat noch) hat die Hülle viel von diesem Job gemacht; Es wurde automatisch in einer Textdatei mit ausführbarem Modus ausgeführt, wenn der Name der Textdatei als Befehl eingegeben wurde. Wenn Sie die Einrichtung in das System einsetzen, können Sie die folgenden Vorteile haben. 1) Es macht Shell -Skripte eher wie echte ausführbare Dateien, da sie Gegenstand von 'Exec' sein können. 2) Wenn Sie eine 'PS' machen, während ein solcher Befehl ausgeführt wird, erscheint sein richtiger Name anstelle von 'sh'. Ebenso erfolgt die Buchhaltung auf der Grundlage des richtigen Namens. 3) Shell -Skripte können sein set-user-id.[a] 4) Es ist einfacher, alternative Shells zur Verfügung zu haben. z.B. Wenn Sie das Berkeley CSH mögen, ist keine Frage, welche Shell eine Datei interpretieren soll. 5) Es ermöglicht anderen Dolmetschern, reibungsloser zu passen. Um diese wundervolle Gelegenheit zu nutzen, setzen Sie #! /bin/sh am linken Rand der ersten Zeile Ihrer Shell -Skripte. Blankchen danach! Ist ok. Verwenden Sie einen vollständigen Pfadnamen (es erfolgt keine Suche). Im Moment ist die gesamte Linie auf 16 Zeichen beschränkt, aber diese Grenze wird angehoben.

Der Schöpfer des Feature gab ihm jedoch keinen Namen:[28]

Aus: "Ritchie, Dennis M (Dennis) ** Ctr ** "  Zu: <[redacted]@talisman.org> Datum: Do, 19. November 2009 18:37:37 -0600 Thema: BETREFFEND: Was tun -Sie- Anruf dein #! <etwas> Linie?  Ich kann mich nicht erinnern, dass wir ihm jemals einen richtigen Namen gegeben haben. Es war ziemlich spät, dass es hereinging-ich denke, ich habe die Idee von jemandem bei einer der UCB-Konferenzen auf Berkeley Unix bekommen; Ich war vielleicht einer der ersten, der es tatsächlich installierte, aber es war eine Idee, die ich von anderswo bekam. Was den Namen betrifft: Wahrscheinlich etwas beschreibend wie "Hash-Bang", obwohl dies einen spezifisch britischen Geschmack hat, aber auf jeden Fall erinnere ich mich nicht besonders an einen Haustiernamen für die Konstruktion.

Kernelunterstützung für Dolmetscheranweisungen, die sich auf andere Versionen von UNIX verbreiten, und eine moderne Implementierung ist in der Linux -Kernelquelle in zu sehen fs/binfmt_script.c.[29]

Mit diesem Mechanismus können Skripte in praktisch jedem Kontext verwendet werden, das normale kompilierte Programme, einschließlich der vollständigen Systemprogramme, und sogar als Dolmetscher anderer Skripte. Als Einschränkung haben einige frühe Versionen von Kernel die Länge der Dolmetscheranweisung jedoch auf rund 32 Zeichen (nur 16 in seiner ersten Implementierung) beschränkt, den Interpreter -Namen nicht aus den Parametern in der Richtlinie aufgeteilt oder andere Macken hatten . Darüber hinaus ermöglichen es in einigen modernen Systemen den gesamten Mechanismus für Sicherheitszwecke eingeschränkt oder deaktiviert (z. B. wurde für Skripte auf vielen Systemen die Unterstützung von Set-User-ID deaktiviert).

Beachten Sie, dass selbst in Systemen mit Vollkern -Unterstützung für die #! magische ZahlEinige Skripte ohne Dolmetscheranweisungen (obwohl es normalerweise noch ausführende Erlaubnis erfordern) sind aufgrund des Legacy -Skripts der Bourne -Shell, die in vielen seiner modernen Nachkommen immer noch vorhanden sind, immer noch ausführbar. Skripte werden dann durch die Standard -Shell des Benutzers interpretiert.

Siehe auch

Anmerkungen

  1. ^ Die SetUID -Funktion ist in den meisten modernen Betriebssystemen deaktiviert, nachdem die Erkenntnis a Rassenbedingung kann genutzt werden, um das Skript zu ändern, während es verarbeitet wird.[27]

Verweise

  1. ^ "Advanced Bash Scripting Guide: Kapitel 2. Beginnen Sie mit einem Sha-Bang". Archiviert Aus dem Original am 10. Dezember 2019. Abgerufen 10. Dezember 2019.
  2. ^ Cooper, Mendel (5. November 2010). Advanced Bash Scripting Guide 5.3 Band 1. lulu.com. p. 5. ISBN 978-1-4357-5218-4.
  3. ^ MacDonald, Matthew (2011). HTML5: Das fehlende Handbuch. Sebastopol, Kalifornien: O'Reilly Media. p. 373. ISBN 978-1-4493-0239-9.
  4. ^ Lutz, Mark (September 2009). Python lernen (4. Aufl.). O'Reilly Media. p. 48. ISBN 978-0-596-15806-4.
  5. ^ Guelich, Gundavaram und Birznieks, Scott, Shishir und Gunther (29. Juli 2000). CGI -Programmierung mit Perl (2. Aufl.). O'Reilly Media. p.358. ISBN 978-1-56592-419-2.
  6. ^ Lie Hetland, Magnus (4. Oktober 2005). Python beginnen: vom Anfänger zum Profi. Apress. p. 21. ISBN 978-1-59059-519-0.
  7. ^ Schitka, John (24. Dezember 2002). Linux+ Handbuch zur Linux -Zertifizierung. Kurs Technologie. p. 353. ISBN 978-0-619-13004-6.
  8. ^ a b "Execve (2) - Linux Man Page". Abgerufen 21. Oktober 2010.
  9. ^ Corbet, Jonathan. "Der Fall des übergroßen Shebang". Lwn.net.
  10. ^ "Srfi 22".
  11. ^ "Python - Python3 Shebang Line funktioniert nicht wie erwartet".
  12. ^ "Die offenen Gruppenbasisspezifikationen Ausgabe 7". 2008. Abgerufen 5. April 2010.
  13. ^ "Pixelbeat.org: Common Shell Skript Fehler". Es ist viel besser, Skripte nach Möglichkeit direkt in einer POSIX -konformen Shell zu testen. Die Option "Bash -Posix" reicht nicht aus, da sie immer noch einige "Bashismen" akzeptiert
  14. ^ "Kapitel 2. Shell -Befehlssprache", Die offenen Gruppenbasisspezifikationen (IEEE STD 1003.1-2017) (Ausgabe 7 Ed.), IEEE, 2018 [2008], Wenn die erste Zeile einer Datei der Shell -Befehle mit den Zeichen "#!" Beginnt, sind die Ergebnisse nicht spezifiziert.
  15. ^ Autoconf, Free Software Foundation, MACRO: AC_SYS_INTERPRETER: Überprüfen Sie, ob das System das Starten von Skripten mit einer Zeile des Formulars "#!/Bin/sh" unterstützt, um den Interpreter für das Skript auszuwählen.
  16. ^ "/usr/bin/env Verhalten". Mail-Index.netbsd.org. 9. November 2008. Abgerufen 18. November 2010.
  17. ^ env (1)- -Freebsd Allgemeine Befehle Handbuch
  18. ^ "Env -Aufruf". GNU CoreUtils. Abgerufen 11. Februar 2020.
  19. ^ "Die Kutschenrendite bewirkt, dass Bash scheitert". 8. November 2013.
  20. ^ "GNU Autoconf Handbuch V2.57, Kapitel 10: tragbare Shell -Programmierung". Archiviert von das Original am 18. Januar 2008. Abgerufen 14. Mai 2020.
  21. ^ "Die #! Magie, Details über den Mechanismus von Shebang/Hash-Bang an verschiedenen Unix-Aromen". Abgerufen 14. Mai 2020.
  22. ^ "FAQ-UTF-8, UTF-16, UTF-32 & BOM: Kann ein UTF-8-Datenstrom das BOM-Zeichen enthalten (in UTF-8-Form)? Wenn ja, kann ich dann immer noch die verbleibenden UTF-8-Bytes annehmensind in Big-Endian-Reihenfolge? ". Abgerufen 4. Januar 2009.
  23. ^ "Jargon -Dateieintrag für Shebang". Catb.org. Abgerufen 16. Juni 2010.
  24. ^ Wand, Larry. "Perl haben keine Skripte, die in der ersten Zeile zwischen dem Shebang und dem Dolmetschernamen einen Platz hatten.". Usenet.
  25. ^ a b "CSRG Archiv CD-ROMs".
  26. ^ Unix Time-Sharing-System: UNIX-Programmierhandbuch (PDF), vol.2a (siebte Ausgabe), Januar 1979
  27. ^ Killes. "Linux - Warum ist SUID für Shell -Skripte deaktiviert, aber nicht für Binärdateien?". Austausch für Informationssicherheitsstapel.
  28. ^ Richie, Dennis. "Dennis Ritchie und Hash-Bang".Talisman.org. Abgerufen 3. Dezember 2020.
  29. ^ Rubini, Alessandro (31. Dezember 1997). "Mit binären Formaten spielen". Linux Journal. Abgerufen 1. Januar 2015.

Externe Links