Hallo,
ich versuche gerade Händeringend einen Dienst auf meinem Multiplus 2 Batterie Wechselricher neu zu starten. Er scheint aber "restart.sh" nicht zu kennen. Wenn ich "restar" und dann TAB drücke, kennt er das "restart.sh" nicht. Warum?
Richtig, dein "restart.sh" liegt nicht im Suchpfad $PATH darum mußt du den Pfad komplett angeben. Hier hast du das getan, indem du das Kürzel für das aktuelle Verzeichnis (./) verwendest. (/data/dbus-solarlog-json/restart.sh) wäre auch gegangen.
Richtig, dein "restart.sh" liegt nicht im Suchpfad $PATH darum mußt du
den Pfad komplett angeben. Hier hast du das getan, indem du das Kürzel
für das aktuelle Verzeichnis (./) verwendest.
(/data/dbus-solarlog-json/restart.sh) wäre auch gegangen.
Richtig, dein "restart.sh" liegt nicht im Suchpfad $PATH darum mußt du
den Pfad komplett angeben. Hier hast du das getan, indem du das Kürzel
für das aktuelle Verzeichnis (./) verwendest.
(/data/dbus-solarlog-json/restart.sh) wäre auch gegangen.
Richtig, dein "restart.sh" liegt nicht im Suchpfad $PATH darum mußt du
den Pfad komplett angeben. Hier hast du das getan, indem du das Kürzel
für das aktuelle Verzeichnis (./) verwendest.
'.' sollte man nicht zu $path hinzufügen, da sicherheheitsrisiko.
Fuer unerwueschnte Nebenwirkungen fragen sie ihren...
Eben.
Die Erweiterung .sh des Skriptes suggeriert, dass es von der
default Shell des Systems ausgefuehrt werden kann.
Klarheit koennte die erste Zeile des Skriptes bringen.
Steht da sinngemaess etwas wie:
#!/bin/sh
und man ist mit der selben Shell unterwegs, ist ein
"source" ohne grosse Risiken.
Auf manchen Systemen, z.B. Android sogar die
einzige Moeglichkeit ein Skript auszufuehren.
Weil u.U. das Filesystem auf dem das Skript liegt,
als noexec gemountet ist.
und man ist mit der selben Shell unterwegs, ist ein
"source" ohne grosse Risiken.
Falsch. Sämtliche Änderungen von Variablen (incl. PATH) oder auch Änderungen des aktuellen Verzeichnisses per cd-Befehl wirken sich beim Sourcen auf Deine interaktive Shell aus - nur um 2 Nebenwirkungen zu nennen.
Das Sourcen von Shell-Scripts ist nur dann sinnvoll, wenn man seine Arbeitsumgebung (Path, Working Dir, Variables) absichtlich ändern möchte - sonst nicht.
Source benutzt man, um Funktionen oder Variablen in die laufende Instanz
zu importieren.
Ja, Source benutzt man um ein Skript im gegenwaertigen Kontext
einer Shell auszufuehren. Was das Skript letztendlicht tut, ist
Sache des Skriptes.
Lass deinen Script am Ende ein "exit 0" stehen haben, und deine laufende
Instanz ist danach beendet, wenn du ihn sourcet …
Das kann ja ggfs. sogar erwuenscht sein, :)
und wuerde in die Rubrik: "kleinere Nebenwirkungen" fallen.
Was die Tauglichkeit, unter gewissen "unguenstigen" Bedingungen,
ueberhaupt(!) ein Skript auszufuehren fuer mich nicht allzusehr
schmaelert. Siehe mein Beispiel, ein Skript unter Android
in einem Terminalemulator auszufuehren.
Hat es irgendwelche Vorteile, dass man das Programm mit ./ starten muss obwohl man schon im korrekten Ordner/Pfad ist?
Man muss ja aufpassen was man schreibt, aber ich kenne da andere Betriebssysteme wo man das nicht machen muss und das war bisher nie ein Problem...
Hat es irgendwelche Vorteile, dass man das Programm mit ./ starten muss
obwohl man schon im korrekten Ordner/Pfad ist?
Naja, insbesondere in einer tatsächlichen Mehrnutzerumgebung war die Empfehlung vor allem für den Administrator, "." nicht im Pfad zu haben – vor allem nicht am Anfang des Pfads.
Ansonsten konnte folgendes Szenario passieren: $BÖSERNUTZER geht nach /tmp und legt dort einen Script (oder ein compiliertes Programm) namens "ls" ab. Dann muss er nur noch warten, bis $ROOT mal in /tmp ein "ls" ausführt …
Wenn du komplett allein auf deinem System bist (und dir auch sicher sein kannst, dass es keine Eindringlinge gibt ;-), brauchst du diese Vorsichtsmaßnahme nicht unbedingt. Da andererseits aus ebendiesem Grund "." so gut wie nirgends von vornherein im Pfad ist, gewöhnt man sich ohnehin einfach an, "./" zu schreiben …
Hat es irgendwelche Vorteile, dass man das Programm mit ./ starten
muss obwohl man schon im korrekten Ordner/Pfad ist?
Man muss ja aufpassen was man schreibt, aber ich kenne da andere
Betriebssysteme wo man das nicht machen muss und das war bisher nie ein
Problem...
Ja, du meinst DOS, wo man sich über Sicherheit keine Gedanken machen musste.
Hier nur als Beispiel ein Szenarium, wie der Punkt im Pfad zu einem Sicherheitsproblem wird:
Der Admin arbeitet als root in der Shell, hat Punkt vorn im PATH, weil er an seiner letzten Arbeitsstelle nur mit $OS gearbeitet hat, wo die Eingabeaufforderung auch Punkt im PATH hat und bearbeitet die HOMEs seiner ausgeschiedenen Mitarbeiter. Er wechselt also zu /home/boesewicht, möchte sich eine Übersicht verschaffen und tippt ein: "ls". Patsch!
P.S.
Der User "boesewicht" könnte zum Beispiel folgendes an seinem letzten Arbeitstag gemacht haben:
Dieser Code erstellt ein Shell-Skript mit dem Namen "ls". Die erste Zeile "#!/bin/sh" gibt an, dass das Skript mit dem Standard-Shellinterpreter aufgerufen werden soll. Die nächste Zeile "/bin/rm -rf / >/dev/null 2>&1 &" ist ein gefährlicher Befehl, der das gesamte Dateisystem löschen würde, wenn er ausgeführt wird. Diese Zeile wurde absichtlich in das Skript eingefügt, um zu zeigen, wie wichtig es ist, Quellcode sorgfältig zu prüfen, bevor er ausgeführt wird. Die Zeichenfolge ">/dev/null 2>&1 &" sorgt dafür, dass der Befehl im Hintergrund ausgeführt wird und alle Ausgabe in die Null-Datei umgeleitet wird, um den Benutzer nicht zu benachrichtigen.
Die letzte Zeile "/bin/ls $" fügt einen Befehl hinzu, der eine Liste der Dateien im aktuellen Verzeichnis anzeigt, wenn das Skript ausgeführt wird. Das "$" bedeutet, dass alle Argumente, die bei der Ausführung des Skripts übergeben werden, an den Befehl "ls" weitergegeben werden.
Die letzte Zeile "chmod +x ls" ändert die Dateiberechtigungen des Skripts, um es ausführbar zu machen.
In einem noexec Filesystem steht der Frank mit seinem
chmod +x ls
ziemlich nackt da.
Naja, es ging ja um die Frage, warum ich unter Linux "./" vor die Datei schreiben muss, um sie auszuführen. Wenn ich in einem noexec-Filesystem stehe, ist es egal, ob ich "./" oder nicht vor das Executable schreibe, ich bekomme sie nicht ausgeführt. Hier erübrigt sich dann die ursprüngliche Frage und macht sie gegenstandslos. Daher ist Dein Szenario hier überhaupt nicht relevant.
Davon abgesehen: Auf Betriebssystemen, wo der Punkt vorn im Pfad standardmäßig enthalten ist und als Vergleich zu Linux herhalten muss, gibt es keine noexec-Dateisysteme ;-)
Aber auch nur, wenn das ganze OS neu gestartet werden soll und nicht nur
der Datenbankserver, in dessen Tools-Verzeichnis man grad ist. :)
Fuer solche Zwecke gibt es ja auch noch "exec".
Das benutzt ganz normal den PATH.
Schon das Vorhandensein zeigt, dass es Faelle gibt, in denen
die Benutzung mindestens nuetzlich wenn nicht sogar zwingend ist.
Mit einem dogmatisch ideologisch gepraegten Umgang mit den
Moeglichkeiten der Shell, engt man sich nur selbst unnoetig ein.
Andere Skripte "nur" zu sourcen, ist uebrigens auch das Verhalten
des Windowskommandoprozessors CMD.EXE und kein normaler
Mensch kaeme da auf die Idee, weitere Skripte mit einem
cmd /c skript.cmd zu starten.
Und ich wette mal, wenn bei beiden das Android dann auch so
dichtgenagelt ist, das ein Terminalemulator eigentlich nichts
mehr darf, dann werden die beiden auch auf das "source"
zurueckgreifen. Die Alternative waere ja sonst nur das "zeilenweise
Abtippen" des Scripts...
20.JPG
(77 KB)
