![](https://seccdn.libravatar.org/avatar/735ea797d876adb026ae955e8adbf597.jpg?s=120&d=mm&r=g)
On Mit, Jan 31, 2001 at 01:50:42 +0100, David Haller wrote:
REF="/var/run/findexec.ref" LOG="/var/log/findexec.log"
trap "exit 0" 1 2 3 6 15 while true; do for f in $(find -type f -maxdepth 1 -cnewer $REF && touch $REF);
Über den Einsatz des find hatte ich auch nachgedacht, das hat aber gegenüber der Variante von Bruno (ls -t | head -1), die ich übernommen habe einen entscheidenden Nachteil: find liefert Dateien unsortiert. Wenn also Scripts, die nacheinander kommen, auf den Ergebnissen vorhergehender Scripts aufbauen, dann hast Du hier schlechte Karten. Damit ist u. U. $REF auch nicht unbedingt auf dem Stand der neuesten Datei, was in Verbindung mit dem fehlenden -f beim rm dazu führen könnte, dass Scripts mehrfach ausgeführt werden. Nebenbei: Ich habe es nicht ausprobiert - liefert f korrekte Werte bei Dateien mit Leerzeichen im Namen?
do ( $SHELL "$f" || echo "Can't run $f" >> $LOG ) && \ rm "$f" || echo "Can't remove "$f" >> $LOG done sleep 20 done
1. das kein rm -f verwendet wird ist Absicht.
Welche Absicht steckt dahinter? Ich würde eher darauf achten, dass die Datei auf jeden Fall gelöscht wird.
2. Das ganze ist aber IMO eine ziemlich grosse Sicherheitsluecke um nicht -scheunentor zu sagen...
Volles ACK. Das ist eine Einladung: Kommt und bedient Euch in meinem System. Aber wir wissen ja nicht, woher die Scripts kommen. Wenn das nur aus dem Intranet oder gar dem lokalen Rechner kommt ... Auf jeden Fall etwas, worüber man gründlich nachdenken sollte. Jan