Script Hilfe gesucht!!!

[Benares]

Noch eine Anmerkung zu $0:

Wenn die x-Rechte des Scripts richtig sitzen (z.B. 755) braucht es kein "sh scriptfile.sh", "scriptfile.sh" genügt.
Im zweiten Fall löst $0 den Pfad zum Script auf, im ersten vermutlich nur den Pfad zur Shell.

Edit:
Grad mal probiert mit

#!/bin/sh
echo $0

Auch bei "sh scriptfile.sh" wird "scriptfile.sh" geliefert und nicht "/bin/sh". Von daher war meine Aussage falsch.
Wenn aber "scriptfile.sh" ohne sh davor nicht funktioniert, klappt auch der rekursive Aufruf nicht.

Von daher: Rechte richtig setzen und auf "sh" verzichten.

 

[luddi]

An die Dateiattribute dachte ich auch zuerst, doch nun habe ich es selbst einmal ausprobiert und komme zu folgendem Ergebnis.

Ich habe ein sh file namens "recursive.sh" zum testen mit folgendem Inhalt angelegt :

#!/bin/sh

case "$1" in

  start)
    echo "Parameter \$0:" "$0"  
    "$0" stop
  ;;

  stop)
    echo "done"
  ;;
esac

exit 0

Wenn das file mit Parameter 'start' aufgerufen wird dann wird es sich einmal selbst mit 'stop' aufrufen. Als Kontrollausgabe für die Sequenz 'start' wird der Parameter $0 ausgegeben und für die Sequenz 'stop' wird "done" ausgegeben.

Soweit so gut.

Das File liegt an folgendem Speicherort mit den entsprechenden Attributen, in diesem Fall 755.

/volume1/temp/bash_recursiv # ls -la
d---------    2 root     root          4096 Jan  5 21:42 .
d---------   19 root     root          4096 Jan  5 21:46 ..
-rwxr-xr-x    1 root     root           124 Jan  5 21:44 recursive.sh

a.) Ruft man das sh file nun ohne "sh" auf erhält man folgende Ausgabe:

/volume1/temp/bash_recursiv # recursive.sh start
ash: recursive.sh: not found

b.) Sobald man den relativen Bezug herstellt mit "./" erhält man folgende Ausgabe:

/volume1/temp/bash_recursiv # ./recursive.sh start
Parameter $0: ./recursive.sh
done

c.) Wird das script file mit dem vorangestellten "sh" aufgerufen erhält man folgende Ausgabe:

/volume1/temp/bash_recursiv # sh recursive.sh start
Parameter $0: recursive.sh
recursive.sh: line 13: recursive.sh: not found

d.) Ruft man das script file mit dem absoluten Pfad auf erhält man folgende Ausgabe:

~ # /volume1/temp/bash_recursiv/recursive.sh start
Parameter $0: /volume1/temp/bash_recursiv/recursive.sh
done

Somit möchte ich gerne auf folgende Aussagen Bezug nehmen...

Auch bei "sh scriptfile.sh" wird "scriptfile.sh" geliefert [...]

Das ist korrekt und wird unter Punkt c.) gezeigt.

Wenn aber "scriptfile.sh" ohne sh davor nicht funktioniert, klappt auch der rekursive Aufruf nicht.

Das ist korrekt und unter Punkt a.) nachzuvollziehen. Das script kann ohne sh davor nicht aufgerufen werden, somit ist der rekursive Aufruf ohnehin obsolet.

Von daher: Rechte richtig setzen und auf "sh" verzichten.

Dies konnte ich leider nicht nachvollziehen obwohl alle executive flags gesetzt sind [ rwxr-xr-x ]
Der Aufruf des Scripts ohne "sh" funktioniert nicht, wie bereits unter Punkt a.) gezeigt wurde.

Gruß
luddi

 

[Benares]

Hallo luddi,

du hast dich ja reingekniet - danke dafür.

Du machst aber einen Denkfehler. Der Benutzer "root" hat das das aktuelle Verzeichnis (.) nie mit im Pfad - aus Sicherheitsgründen (Grund kann ich bei Gelegenheit mal erklären, wenn es dich interessiert). "root" muss daher jedes Script zumindest mit ./script aufrufen, selbst wenn er im Verzeichnis des Scripts steht (cd) und das Verzeichnis nicht eh schon im Pfad vorhanden ist. Deshalb kann a) nie klappen. Das ist anders als bei Windows/DOS wo auch im aktuellen Verzeichnis gesucht wird, auch wenn es nicht im Pfad steht.

 

[luddi]

Hi Benares,

ja in der Tat weil ich den Drang hatte es gründlich untersuchen zu müssen.

Ich danke auch dir für den Hinweis, das hatte ich bisher auch nicht gewusst. Aber das braucht keinerlei genauere Erklärung für das Verhalten. Es ist für mich jedenfalls plausibel genug, dass das bei root eben aus Sicherheitsgründen so ist.

Somit könnte es genau daran liegen dass 'Kalysto' in seinem script das "sh" benötigt um den rekursiven Aufruf zu realisieren wenn der auszuführende User des Aufgabenplaner (bzw. terminal) "root" ist.

Gruß
luddi

 

[Kalysto]

ich hab das gemacht wie @luddi zuvor schon gezeigt und gesagt hatte ich habe meinen PFAD in die PATH dabei eingetragen und siehe da es geht ohne sh
alles Perfekt ^^

 

[luddi]

Auch mit "sh" hättest du es ja zum laufen bekommen in deinem Fall. Nur wollte ich selbst untersuchen und verstehen woran das liegt. Nun weiß ich es und du scheinst eine Lösung gefunden zu haben. Das freut mich natürlich auch.

Gruß
luddi

 

[Kalysto]

ja da hast du recht es währe auch so gegangen aber ich war auch neugierig und wollte mal testen und siehe da es geht dann wirklich
danke dir =)

lg
kalysto

 

[luddi]

Und ich habe hier auch wieder was durch 'Benares' seinen Beitrag gelernt indem er mir mit seiner Anmerkung zu $0 eine Steilvorlage gegeben hat.

Danke auch von meiner Seite.

Gruß
luddi

 

[Benares]

Somit könnte es genau daran liegen dass 'Kalysto' in seinem script das "sh" benötigt um den rekursiven Aufruf zu realisieren ...

Noch eine Anmerkung dazu zum Schluss.
Nein er braucht "sh" nicht, er muss nur darauf achten, immer den Pfad (oder halt ./ wenn zuvor cd dorthin) mit anzugeben, wenn das Script aufgerufen und auch unter root lauffähig sein soll.

Auch zum Thema "warum darf root "." nicht im Pfad haben" will ich noch die Begründung loswerden.
Stellt euch mal vor, luddi wäre Admin und erteilt mir (einem normalen User) Zugriffsrechte. Ich melde mich an und leg ihm mit einem Script namens "ls" in /tmp ein Ei ins Nest

#!/bin/sh
#
# /tmp/ls - mein Hacker "ls" - löscht alles - Gruß Benares
rm -rf /*

und setz die Rechte auf 755. Darf ich alles, denn /tmp ist normalerweise offen für alle.

Nun kommt luddi, meldet sich als "root" an, navigiert durch die Verzeichnisse und schaut auch mal in /tmp nach, was dort alles abliegt

cd /tmp
ls

Was passiert wohl, wenn "." (vorne) mit im Pfad ist? - richtig, das System ist hinüber!

Deshalb darf bei "root" niemals das aktuelle Verzeichnis mit im Pfad sein und "normale" Benutzer dürfen auch keine Schreibrechte auf Verzeichnisse, die im Pfad enthalten sind, besitzen.

Ist nur ein mögliches Beispiel.

 

[luddi]

Noch eine Anmerkung dazu zum Schluss.
Nein er braucht "sh" nicht, er muss nur darauf achten, immer den Pfad (oder halt ./ wenn zuvor cd dorthin) mit anzugeben, wenn das Script aufgerufen und auch unter root lauffähig sein soll.

Nichts anderes wollte ich sagen, all das ist mir selbst bewusst. Nur habe ich Bezug auf seine geschilderte Situation genommen. Da er das script mit "sh script.sh" aufgerufen hat, so muss der rekursive Aufruf im script selbst auch mit "sh" oder aber mit "./" (bzw. absoluter Pfad, oder mit cd dort hin wechseln) aufgerufen werden.

Danke dass du die Begründung los geworden bist und nicht für dich behalten hast, denn das ist wirklich ein exzellentes Beispiel.

Gruß
luddi

 

[dil88]

Sehr schön ausgeführt, danke dafür, Benares!

 

[Kalysto]

Noch eine Anmerkung dazu zum Schluss.
Nein er braucht "sh" nicht, er muss nur darauf achten, immer den Pfad (oder halt ./ wenn zuvor cd dorthin) mit anzugeben, wenn das Script aufgerufen und auch unter root lauffähig sein soll.

Auch zum Thema "warum darf root "." nicht im Pfad haben" will ich noch die Begründung loswerden.
Stellt euch mal vor, luddi wäre Admin und erteilt mir (einem normalen User) Zugriffsrechte. Ich melde mich an und leg ihm mit einem Script namens "ls" in /tmp ein Ei ins Nest

#!/bin/sh
#
# /tmp/ls - mein Hacker "ls" - löscht alles - Gruß Benares
rm -rf /*

und setz die Rechte auf 755. Darf ich alles, denn /tmp ist normalerweise offen für alle.

Nun kommt luddi, meldet sich als "root" an, navigiert durch die Verzeichnisse und schaut auch mal in /tmp nach, was dort alles abliegt

cd /tmp
ls

Was passiert wohl, wenn "." (vorne) mit im Pfad ist? - richtig, das System ist hinüber!

Deshalb darf bei "root" niemals das aktuelle Verzeichnis mit im Pfad sein und "normale" Benutzer dürfen auch keine Schreibrechte auf Verzeichnisse, die im Pfad enthalten sind, besitzen.

Ist nur ein mögliches Beispiel.

wenn du das hier nun so sagst habe ich das dann richtig entnommen das ich den PFAD zu der Datei .sh nie in die PATH dabei einlegen sollte ??
hab ich das so richtig verstanden ??

 

[dil88]

Nein. Benares weißt darauf hin, dass der Pfad, in dem man sich gerade befindet und der unter Unix mit dem Punkt (".") bezeichnet wird, für den Superuser root nicht in der PATH-Variable steht und stehen sollte. Bei normalen Usern steht er in der PATH-Variablen und fixe Pfade wie /bin, /sbin oder /usr/bin stehen generell in der PATH-Variablen.

 

[Kalysto]

achso okay danke für die Erklärung