ausführen Shell-Skript ohne implizit aufrufen sh

Question

Ich frage mich, ob es möglich ist, eine "Verknüpfung" in usr/bin (d. H.), Die zu einem Shell-Skript führt.

Aber ich will nur

% shellscript 

statt

% sh shellscript.sh 

irgendwie wie ein Alias ​​schreiben.

Ist das möglich?

Answer 1

Sprechen Sie die erste Zeile des Skripts

#!/bin/sh 

Dann ist es, indem Sie den Befehl ausführbar machen:

chmod +x shellscript.sh 

Wenn Sie jetzt das Skript in einem bin Ordner platzieren, die auf Ihrem System ist PATH Variable und Sie können es direkt ausführen. Um die Ordner in Ihrem Pfad, Typ:

echo $PATH 

ich in der Regel /home/[my username]/bin für Skripte verwenden, die ich geschrieben habe, so dass sie nicht mit anderen Benutzern im System stören. Wenn ich möchte, dass sie für alle Benutzer sind, verwende ich /usr/local/bin, die auf den meisten Distributionen leer geliefert wird.

Die .sh am Ende des Dateinamens des Skripts ist nur eine Konvention, die Ihnen hilft, sich daran zu erinnern, um welche Art von Datei es sich handelt. Es funktioniert immer noch, wenn Sie es zum Beispiel in nur shellscript umbenennen, das Ihre Anforderungen vervollständigt.

Answer 2

Sie können das Shell-Skript ausführbar machen (chmod +x shellscript.sh). Dann können Sie von/usr/bin (ln -s shellscript.sh /usr/bin/shellscript) zu ihm verknüpfen.

Answer 3

Ja. Sie können ln verwenden, um eine Verknüpfung zu shellscript.sh namens shellscript zu erstellen. Sie müssen es dann ausführbar machen, aber danach (vorausgesetzt, /usr/bin ist auf Ihrem Pfad) können Sie es mit shellscript ausführen.

Answer 4

Neben das Skript ausführbar zu machen und sie in/usr/bin Verknüpfung, wie andere vorgeschlagen haben, werden Sie auch die „Shebang“ Linie an die Spitze des Skripts hinzufügen möchten:

#!/bin/sh 

# your commands here 

Damit können Sie angeben, welcher Shell-Interpreter (bash, bourne shell, c-shell, perl, python ...) verwendet werden soll, um Ihr Skript auszuführen.

Answer 5

Ich dachte über diese Frage der Verwendung von Dateinamenerweiterungen in Unix/MacOSX nach und die beste Antwort, die ich zur Verfügung stellen kann, ist eine Paste aus meiner Entwicklung Kommentare in einigen Code ich vor Jahren geschrieben, um den ganzen langwierigen Prozess der Aktualisierung von Skripts zu automatisieren schreibe ich für die Aufnahme in/usr/local/bin.

I have begun to 
change how I develop code for my contributions to 
/usr/local/bin. In the past I would always leave the development 
file without an extension and depend on the shebang 
#!/usr/bin/env ...) line. The flaw with using this approach 
exclusively is it does not allow me to utilize the code colorizing 
capabilities I have available for programming languages as deftly 
as I might. Also allot of development environments do not 
understand shebang and so see the code as plain text. Nor are the 
contents of files without file extensions accessible via the MacOSX 
QuickLook feature... 

Kurz gesagt, mein Automatisierungscode (und nicht zu viel hier posten) ‚sudo‘ fügt eine ausführbare Erweiterung lose Kopie des Programms in/usr/local/ist, aber die Datei im Verzeichnis Entwicklung hält es Skript-/Programmsprachenerweiterung vorhanden. Beide Kopien haben die gleiche Shebang-Zeile am Anfang der Datei.Viele andere sich wiederholende Aufgaben sind natürlich auch in diesem Automatisierungscode automatisiert. Aber die ultimative Belohnung ist der "Overhead", der mit dem Prozess verbunden ist, neue 'Befehle' zu schreiben oder existierende/usr/local/bin 'Befehle zu optimieren, dauert jetzt ein paar Tastenanschläge.

Ich bleibe auf Snow Leopard und bleiben vorsichtig Lion. Also, wenn die Dinge auf Lion anders sind, entschuldige ich mich für jede Verwirrung. Auch wenn Ihr Betriebssystem nicht das Äquivalent von QuickLook hat, kann etwas von dem, was ich gesagt habe, bei Ihnen verloren gehen, aber ich denke, jeder Linux/Unix-Benutzer kann immer noch von der Code-Kolorisierung über den vim/less profitieren (http: // www- zeuthen.desy.de/~friebel/unix/less/README) Befehle.

Ein Beispiel für einige meine automatisierten Text colorizing Code-Ausgabe, das QuickLooking durch Code in dem Entwicklungsverzeichnis erleichtert:

/usr/bin/highlight --syntax sh --style neon -i "/Users/pcs/Projects /Shell/Bash/findpdftext/findpdftext.sh" >| "/Users/pcs/Projects/Shell /Bash/findpdftext/findpdftext.sh.html" 

diese vorformulierten html generieren kostet mich nichts und ist schöner in Info als die man-Seiten, die Auch automatisch generiert. Ein weiteres kleines Beispiel für eine automatisierte Ausgabe, die in das Skript im Entwicklungsverzeichnis des Programms eingefügt wird, das ausgeführt wird, wenn ich bereit bin, Änderungen an dem betreffenden Skript in die 'Befehlskopie' in/usr/local/bin zu schreiben:

##################################### REWIRE findpdftext.sh: 
chmod 777 "/Users/pcs/Projects/Shell/Bash/findpdftext/findpdftext.sh" 
cp -f "findpdftext.sh" "findpdftext" 
sudo ln -f "findpdftext" /usr/local/bin 
cp -f "findpdftext" "/Users/pcs/man/cat1/findpdftext.1" 

############### SYMBOLIC-LINK-NAMES supplied from command-line: 
##### fpdf is a symbolic link to findpdftext 
sudo ln -s -f "/usr/local/bin/findpdftext" "/usr/local/bin/fpdf" 
cp -f "/usr/local/bin/findpdftext" "/Users/pcs/man/cat1/fpdf.1" 

############### SYMBOLIC-LINK-NAMES supplied from command-line: 
##### fpt is a symbolic link to findpdftext 
sudo ln -s -f "/usr/local/bin/findpdftext" "/usr/local/bin/fpt" 
cp -f "/usr/local/bin/findpdftext" "/Users/pcs/man/cat1/fpt.1" 

Abschließend gibt es für mich Gründe für die Verwendung beider Dateibenennungsstile.