Diskussion:Shebang

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Die Formulierung "eingebaut werden können" (in eine Datei) kann irreführend wirken. Besser ist das einfache Wort "schreiben".... Less is more..... -- WeltBessereDich 22:42, 9. Aug. 2008 (CEST)

Abschnitt "Windows"[Quelltext bearbeiten]

Da Windows ein anderes System hat, Ordner und Partitionen anzusprechen, und es auch keinen standardisierten Pfad zu Anwendungsprogrammen gibt, gibt es quasi keine einheitliche Shebang-Zeilen, die für mehrere Windows-Installationen Gültigkeit hätten.

Seltsam; einen Abschnitt weiter oben ging es darum, dass unter *IX %PATH% verwendet wird, und nun wird das ganz anders für Windows dargestellt? Da stimmt was nicht.
-- Tuxman 00:29, 17. Jul. 2009 (CEST)

Lies genauer: Im Abschnitt oben steht, dass bei der Shebang #!/usr/bin/env die Pfadvariable durchsucht wird. Ich kenne keine Windows-Alternative zu env. --BerntieDisk. 00:54, 17. Jul. 2009 (CEST)
Naja, beide Formulierungen waren nicht hinreichend. Vielleicht ist das ein brauchbarer Kompromiss? --Benji 01:21, 17. Jul. 2009 (CEST)
Gefällt mir besser, ja. :-)
-- Tuxman 01:39, 17. Jul. 2009 (CEST)

Abschnitt Implementierung[Quelltext bearbeiten]

„Damit kann der Kernel des Betriebssystems die Datei bereits als Skript erkennen und mit dem angegebenen Interpreter ausführen.“ ist m. E. so nicht richtig. Für die Auswertung der Shebang-Zeile ist meines Wissens die Shell zuständig, die dann entsprechend den Programmaufruf substituiert. Der Prozessmanager (als Teil des Kernels) sieht dann nur das Binary des Interpreters (plus Parameter), in etwa so als häte ein Benutzer den Befehl auf der Kommandozeile eingegeben. Siehe z.B. [1], [2] und [3]. --IrrwahnGrausewitz 13:43, 1. Sep. 2010 (CEST)

Die vorherige Version war richtig, der Shebang wird im execve-Systemaufruf (oder seinen Varianten), also vom Kernel ausgewertet. Eine Shell ist daran nicht beteiligt. Siehe z. B. den ersten Absatz der Linux-Manpage für execve.
Dass die Bash (beispielsweise) den Shebang ignoriert, zeigt folgendes Experiment:
Anzeige des Inhaltes des Skriptes:
$ cat shelltest
#!/bin/cat
Hello World!
Ausführung: der Kernel involviert /bin/cat als "Interpreter":
$ ./shelltest
#!/bin/cat
Hello World!
Ausführung mit Bash: der Shebang wird (als beliebiger Kommentar) ignoriert:
$ bash shelltest
shelltest: line 2: Hello: command not found
$  
Habe den Abschnitt entsprechend korrigiert. --Mosmas 14:22, 29. Mär. 2011 (CEST)

Kommentar in der Skriptsprache[Quelltext bearbeiten]

In finde den Absatz sehr ungelücklich und wohl auch am Thema vorbei. Ich kenne REXX nicht, kann also nicht beurteilen wie gross die Probleme bei REXX sind. Aber wenn es Probleme gibt, dann liegt es wohl eher daran, dass die Sprache nicht für Unix entwickelt wurde.

Bei PHP gibt es ganz sicher keine Probleme obwohl der Artikeltext dies suggeriert und obwohl PHP kein Lattenkreuz als Kommentar verwendert. Hier ein Beispiel:

#!/usr/bin/php
Diese Zeile wird vom PHP interpreter ignoriert und einfach ausgegeben.
Die shebang-Zeile ganz oben wird aber nicht ausgegeben!
# Diesen Kommentar kann man sehen. 
<?php
  echo "Der PHP-Interpreter sagt: Hallo Welt\n";
?>
Diese Zeile wird ebenfalls vom PHP interpreter ignoriert und einfach ausgegeben.
<?php
  die("... dei die() dei ... das Programm ist tot ...\n");
?>
Diese Zeile lässt selbst der PHP-Interpreter nicht mehr durchgehen.

Wird das Beispiel in die Datei ./shebang-test.php gespeichert und die Flags entsprechend gesetzt, dann kann man das Programm auf der Kommandozeile mit "./shebang-test.php" oder "php -f ./shebang-test.php" aufrufen. Beide Methoden funktioneren perfekt.

Den Absatz sollte man vieleicht in "Probleme mit Nicht-Unix-Sprachen" oder so ähnlich umbenennen und entsprechend textlich ein bischen anpassen. Vieleicht auch beschreiben wie man diese Probleme umschiffen kann (HereDoc o.ä.).

Gibt es andere Meinungen? --Nohome 18:22, 27. Jan. 2011 (CET)

Was isn eine Unix-Sprache?
-- Tuxman 11:13, 28. Jan. 2011 (CET)
Das Problem ist doch, wenn die Sprache nicht die Raute als Zeilenkommentar beinhaltet, und REXX hat C-ähnliche Kommentarzeichen (/* bla */). Aber OOREXX als REXX-Implementierung hat da etwa genauso wie PHP eine Sonderbehandlung, dass die erste Zeile schlicht ignoriert wird, wenn #! vorgefunden wird. Unix-Sprache ist ein unpraktischer Begriff (steht auch nicht so im Artikel), aber es ist ja klar, was gemeint ist: Sprachen, die nicht für oder zumindest auf unixoiden Systemen entwickelt wurden. --Benji 01:57, 31. Jan. 2011 (CET)
Klingt nach WP:TF.
-- Tuxman 21:26, 31. Jan. 2011 (CET)
Formuliers halt besser. --16:10, 4. Mär. 2011 (CET)

- "und obwohl PHP kein Lattenkreuz als Kommentar verwendert" - doch, tut es. Auch wenn die C/C++-Syntax weiter verbreitet ist. 137.138.36.24 11:26, 4. Mär. 2011 (CET)

PHP erkennt das Lattenkreuz aber nur als einzeiligen Kommentar innerhalb interpretierter Blöcke:
<?php
 # dies ist ein kommentar
?>
 # aber dies ist kein Kommentar.
--Benji 16:10, 4. Mär. 2011 (CET)
Natürlich, denn der Teil außerhalb ist kein PHP-Code.
-- Tuxman 12:44, 5. Mär. 2011 (CET)

Der Absatz wurde durch mich angepasst und ich hoffe, daß es nun klarer wird, was gemeint ist. Es ging dem Autor darum, darauf hinzuweisen, daß nur solche Interpreter über das Shebang aufgerufen werden können, welche das Shebang dann selbst ignorieren, da ja das gesamte Script an den Interpreter übergeben wird - im Idealfalls also dadurch, daß es als Kommentar gewertet wird. Wenn damit die Diskussion beendet ist, kann der Hinweis auf Korrektur entfernt werden. --Daniel "Quippy" Becker (Diskussion) 08:44, 23. Sep. 2015 (CEST)

Sinn & Zweck aus Artikel nicht ersichtlich.[Quelltext bearbeiten]

Was bringt Shebang für einen Vorteil gegenüber dem direkten Aufruf des zuständigen Interpreters mit dem Skript als Parameter? --217.231.64.84 15:04, 3. Jun. 2013 (CEST)

Mindestens zwei Vorteile: Erstens kann ein Anwender das Skript wie ein Kommando aufrufen und benutzen, ohne den Interpreter und weitere Details (s. u.) kennen zu müssen. Zweitens kann der Interpreter – ggf. einschließlich benötigter Aufrufargumente – exakt definiert werden; beispielsweise könnte eine Interpreterversion mit besonderen, für die Funktionsweise des Skriptes unerlässlichen Eigenschaften in einem speziellen Verzeichnispfad installiert sein, oder das Skript funktioniert nur, wenn der Interpreter mit bestimmten Optionen gestartet wird. Sollte man vielleicht im Artikel noch ergänzen. --Mosmas (Diskussion) 19:31, 3. Jun. 2013 (CEST)
Es mag sein, dass Motivation und Hintergrund im Artikel ungenügend deutlich werden.
Ein weiterer Grund: Würden Parameter und Infos über das spezifische Skript nicht in dieser Zeile stehen, müsste man auf dem Server ein README danebenlegen. Wenn jemand das Skript herunterlädt oder mailt, muss aufgepasst werden, das README mit herunterzuladen und zu mailen. Um es zu starten, muss ich erstmal das README öffnen und nachgucken, mit welcher Skriptvariante und welchen Parametern ich es aufrufen muss, weil ich das längst wieder vergessen habe. Da ist es mir lieber, wenn das System selbst nachguckt und das automatisch richtig macht. (Okay, statt gesonderter README könnte man natürlich einen Kommentar an den Anfang des Skriptes schreiben. Auch dann muss ich aber erst nachgucken, mit welchen Parametern ich starten soll.)
Es ist nervig genug, dass die Pfade und Optionen nicht restlos kompatibel sind und man immer mal wieder nach dem ersten Fehlschlag die erste Zeile an die eigene Installation anpassen muss.
Liebe Grüße --PerfektesChaos 00:47, 4. Jun. 2013 (CEST)

S-Bits[Quelltext bearbeiten]

Gelöscht: "Bei Skripten mit Shebang werden vom Linuxkernel die SUID- und SGID-Flags ignoriert." Dies gilt auf den meisten Systemen generell für Skripte - unabhängig davon, ob sie den Shebang enthalten oder nicht (siehe Setuid). Das tut hier also nichts zur Sache. --Mosmas (Diskussion) 15:23, 9. Sep. 2015 (CEST)