Es scheint, als ob ein Skript mit #! Präfix kann den Namen des Interpreters und NUR ein Argument haben. Also:Einschränkungen von #! in Skripten
#!/bin/ls -l
funktioniert, aber
#!/usr/bin/env ls -l
nicht
Stimmen Sie zu? Irgendwelche Gedanken?
Francesc
Verschiedene Unixe interpretieren #! anders. Hier ist eine umfassend aussehende Writ-up: http://www.in-ulm.de/~mascheck/various/shebang/
Es scheint, dass der kleinste gemeinsame Nenner über Plattformen "der Interpreter (der nicht selbst ein Skript sein muss) und nicht mehr als ein Argument".
Ursprünglich hatten wir nur eine Shell unter Unix. Wenn Sie aufgefordert werden, einen Befehl auszuführen, versucht die Shell, einen der exec() - Systemaufrufe für sie aufzurufen. Wenn der Befehl eine ausführbare Datei war, würde die Exec erfolgreich sein und der Befehl würde ausgeführt werden. Wenn der Befehl exec() fehlschlägt, gibt die Shell nicht auf, sondern versucht, die Befehlsdatei so zu interpretieren, als wäre sie ein Shell-Skript.
Dann bekam Unix mehr Muscheln und die Situation wurde verwirrt. Die meisten Leute würden Skripte in einer Shell schreiben und Befehle in eine andere schreiben. Und jede Shell hatte unterschiedliche Regeln, um einem Dolmetscher Skripte zu geben.
Dies ist, wenn die "#!/"Trick wurde erfunden. Die Idee war, dass die Aufrufe des exec() -Systems des Kernels mit Shell-Skripten gelingen. Wenn der Kernel versucht, eine Datei zu exec() zu machen, sieht er sich die ersten 4 Bytes an, die eine ganze Zahl darstellen, die magische Zahl genannt wird. Dies teilt dem Kernel mit, ob er versuchen sollte, die Datei auszuführen oder nicht. Damit "#!/"Wurde zu den magischen Zahlen hinzugefügt, die der Kernel kennt, und er wurde erweitert, um tatsächlich Shell-Skripte selbst ausführen zu können. Aber einige Leute konnten nicht "#! "Sie haben den Raum immer wieder verlassen. Also wurde der Kernel ein wenig erweitert, damit "#! /" Als spezielle magische 3-Byte-Zahl funktionieren kann.
sehr klare Antwort, danke – francesc