Hallo!
Bisher war ich es gewohnt, Skripte mit ./skript aufzurufen, seit Suse7 scheint das nicht mehr zu gehen (permission denied). Was muss ich machen, damit ich nicht jedes mal sh skript eingeben muss??
Danke
Reto
Das hat mit Suse 7 nix zu tun, das Ding muss executable gesetzt sein.
chmod +x scriptname
dann aufrufen
Moin,
chmod +x scriptname
Das geht? Das sollte es aber nicht, auf jeden Fall sollte man sich das nicht angewöhnen.
Thorsten
Jo das geht… ok vielleicht sollte man es nicht für jeden ausführbar machen, aber auf meinem Rechner häng eh nur ich 
MfG Bruno
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Moin,
chmod +x scriptname
Das geht? Das sollte es aber nicht, auf jeden Fall sollte man
sich das nicht angewöhnen.
Was sollte denn – die entsprechende Rechtevergabe vorausgesetzt – dagegen sprechen? Das ist der Grund, warum „.“ nicht im Suchpfad von root sein sollte. Wer weis, was einem sonst als „ls“ vorgegaukelt wird 
Gruss
Jens
Moin,
chmod +x scriptname
Das geht? Das sollte es aber nicht, auf jeden Fall sollte man
sich das nicht angewöhnen.Was sollte denn – die entsprechende Rechtevergabe
vorausgesetzt – dagegen sprechen?
Welche Rechtevergabe?
Das ist der Grund, warum „.“ nicht im Suchpfad von root
sein sollte. Wer weis, was einem sonst als „ls“
vorgegaukelt wird
Nö. Damit will man nur verhindern, daß root unabsichtlich ein Programm startet, das sich gerade in . befindet.
Ich gebe Rechte immer explizit an, entweder mit User+Recht oder oktal. Daß es auch ohne Angabe des Users geht, wußte ich nicht. Man sollte sich das nicht angewöhnen, nur um ein Zeichen zu sparen, weil dann vielleicht doch mal ein falsches Programm o+x bekommt.
Thorsten
Hi,
chmod +x scriptname
Das geht? Das sollte es aber nicht, auf jeden Fall sollte man
sich das nicht angewöhnen.
Natuerlich geht das - allerdings nur wenn das script von der jeweiligen Shell evaluirbar ist, oder wenn in der ersten Zeile des Scripts angegeben ist, welcher Interpreter das evaluieren soll. Wo ist das Problem???
Gruss
Thorsten
Moin,
Moin moin,
chmod +x scriptname
Das geht? Das sollte es aber nicht, auf jeden Fall sollte man
sich das nicht angewöhnen.Was sollte denn – die entsprechende Rechtevergabe
vorausgesetzt – dagegen sprechen?Welche Rechtevergabe?
Diese Frage hast Du Dir weiter unten sehr schön selbst beantwortet.
Das ist der Grund, warum „.“ nicht im Suchpfad von root
sein sollte. Wer weis, was einem sonst als „ls“
vorgegaukelt wirdNö. Damit will man nur verhindern, daß root unabsichtlich ein
Programm startet, das sich gerade in . befindet.
Genau. Wenn so ein Programm z.B. „ls“ heisst und obendrein von root ausgeführt wird …
Du erkennst das Problem?
Gruss
Jens
Vielen Dank erstmal…
auch, wenn ich gleich gescholten werde: wo finde ich denn den jeweiligen Suchpfad des Users??
Danke
Reto
PATH (war: Skripte in Suse 7)
Moin,
auch, wenn ich gleich gescholten werde: wo finde ich denn den
jeweiligen Suchpfad des Users??
Den aktuellen mit
set|grep ^PATH
gesetzt wird er in SuSE in /etc/profile
Thorsten
Moin,
chmod +x scriptname
Das geht? Das sollte es aber nicht, auf jeden Fall sollte man
sich das nicht angewöhnen.Wo ist das Problem???
Ich kenne das nur mit einem [ugo] vor dem +. In dieser Form gewöhne ich mir das lieber nicht an.
Thorsten
Moin,
Was sollte denn – die entsprechende Rechtevergabe
vorausgesetzt – dagegen sprechen?Welche Rechtevergabe?
Diese Frage hast Du Dir weiter unten sehr schön selbst
beantwortet.
Dir vielleicht, mir nicht.
Du erkennst das Problem?
Ich weiß wohl, warum . nicht im PATH ist, das hat aber nichts damit zu tun, ob man chmod mit oder ohne Angabe von [ugo] aufruft. Wenn der SU so dumm ist, eine unbekannte Datei ausführbar zu machen, wird ihn auch der fehlende . nicht von Dummheiten abhalten können.
Ich sehe die Gefahr, daß man sich ‚chmod +x file‘ angewöhnt, obwohl man go+x nur selten haben will. Ich kann mich momentan nicht erinnern, jemals etwas anderes als ‚u+x‘ ausgeführt zu haben.
Falls ein Zusammenhang zwischen ‚+x‘ und dem PATH besteht, bitte ich nochmal um Erklärung.
Thorsten
Moin,
Was sollte denn – die entsprechende Rechtevergabe
vorausgesetzt – dagegen sprechen?Welche Rechtevergabe?
Diese Frage hast Du Dir weiter unten sehr schön selbst
beantwortet.Dir vielleicht, mir nicht.
Ich habe mal „permissions“ mit „Rechte“ übersetzt. Und „permissions“ werden in der Tat mit chmod gesetzt. Ferner wären da noch chown und chgrp zu nennen, um ggf. Eigentümer (engl. „owner“) und Gruppenzugehörigkeit (engl. „group ownership“) anzupassen
Du erkennst das Problem?
Ich weiß wohl, warum . nicht im PATH ist, das hat aber nichts
damit zu tun, ob man chmod mit oder ohne Angabe von [ugo]
aufruft. Wenn der SU so dumm ist, eine unbekannte Datei
ausführbar zu machen, wird ihn auch der fehlende . nicht von
Dummheiten abhalten können.
Aber auch die user selbst können Dateien ausführbar machen. Sie können allerdings nicht als Eigentümer oder Gruppe „root“ eintragen. Ebensowenig können sie Programme „suid root“ setzen.
Ich sehe die Gefahr, daß man sich ‚chmod +x file‘ angewöhnt,
obwohl man go+x nur selten haben will. Ich kann mich momentan
nicht erinnern, jemals etwas anderes als ‚u+x‘ ausgeführt zu
haben.
Ich schon. Mitunter arbeitet man an größeren Projekten durchaus als Gruppe. Außerdem sind natürlich säckeweise Systemprogramme „a+x“.
Falls ein Zusammenhang zwischen ‚+x‘ und dem PATH besteht,
bitte ich nochmal um Erklärung.
Wie gesagt, die Ausführbarkeit an sich ist nicht das Problem. Wenn man die Programme aber als root unbeabsichtigt ausführt, kann es böse enden. Rein technisch gibt es natürlich keinen direkten Zusammenhang.
Ausserdem gebe ich Dir natürlich in sofern recht, als das ein sorgfältiger Umgang mit Dateirechten immer besser ist, als ein pauschales „a+…“
Ich hoffe, wir können den „Streit“ damit beilegen
Gruss
Jens
Moin,
Aber auch die user selbst können Dateien ausführbar machen.
Klar. Und wenn sie das mit einem bösen Programm tun, soll der ‚.‘, der nicht im Pfad ist, davor schützen.
Ich kann mich momentan nicht erinnern, jemals etwas
anderes als ‚u+x‘ ausgeführt zu haben.Ich schon. Mitunter arbeitet man an größeren Projekten
durchaus als Gruppe.
Klar.
Außerdem sind natürlich säckeweise Systemprogramme „a+x“.
Die habe ich noch nie angefaßt.
Wie gesagt, die Ausführbarkeit an sich ist nicht das Problem.
Wenn man die Programme aber als root unbeabsichtigt ausführt,
kann es böse enden.
Davor soll der ‚.‘, der nicht im Pfad ist, schützen.
Ausserdem gebe ich Dir natürlich in sofern recht, als das ein
sorgfältiger Umgang mit Dateirechten immer besser ist, als ein
pauschales „a+…“
Wenn es denn ein a+… ist, hat man es ja explizit so gewollt. Wenn man nur ‚+x‘ setzt, kann schonmal der falsche die Rechte haben.
Thorsten