• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

ls und pipe

Hallo,

ich möchte per Cron-Job stündlich rar Dateien entpacken. Das mit dem Cron-Job und dem Entpacken ist auch kein Problem, allerdings scheitere ich an dem Einlesen der Dateien. Folgendes habe ich versucht:

ls /tmp/*.rar | /root/extract.sh

Allerdings gibt die Pipe nicht die Dateinamen an die Variablen $1, $2,.. in dem Shellscript weiter.

Schön wäre auch noch eine Prüfung ob überhaupt rar Dateien in /tmp liegen.

Hat dazu jemand eine Idee?

Schöne Grüsse
Jörg
 
mach es doch mit der Kommandosubstitution und einer Schleife:
Code:
for i in `ls /tmp/*.rar`
do
  /root/extract.sh $i
done
die ` sind "shift + `, " also Die Taste links neben der Backspacetaste
 
Super, danke das klappt!

Nur wenn keine rar Datei vorhanden ist bekomme ich die Meldung
ls: /tmp/*.rar: No such file or directory

Gibt es noch eine Möglichkeit das z.B. mit einer if Schleife abzufangen?

Habe folgendes schon ohne Erfolg probiert:
Code:
if [ -f /tmp/*.rar ]; then
  for i in `ls /tmp/*.rar`
  do
    /root/extract.sh $i
  done 
fi
Schöne Grüsse
Jörg
 
Leute, warum baut ihr eigentlich immer unnötige (und gefährliche) "ls"-Aufrufe ein?

Schlecht:
Code:
for i in `ls /tmp/*.rar`
do
  /root/extract.sh $i
done
Besser:
Code:
for i in /tmp/*.rar
do
  /root/extract.sh $i
done
Warum ist das obere schlecht?

1. Weil es mehr Code als notwendig ist

2. Weil es "ls" in einer eigenen Shell startet, d.h. es gibt einen Performanceverlust, verursacht durch den Overhead zweier unnötiger Prozesse (Shell + "ls")

Und warum ist es nicht nur schlecht, sondern auch gefährlich?

Weil "ls" auf vielen Systemen nicht /bin/ls, sondern ein Alias ist, d.h. man kann nie im Voraus wissen, was "ls" wirklich bedeutet.

Und das beste daran: Es löst das Problem mit dem Fall, dass es keine /tmp/*.rar gibt, auch auf einen Schlag: Der bessere Code spuckt keine Fehlermeldung aus, wenn es keine /tmp/*.rar gibt, sondern führt die Schleife einfach nur nicht aus.

Noch besser wäre:
Code:
for i in /tmp/*.rar
do
  /root/extract.sh "$i"
done
Dann werden auch solche /tmp/*.rar-Dateien, die Leerzeichen im Dateinamen enthalten, korrekt behandelt.

--
Noch eine Kleinigkeit zum ursprünglichen Code: Da steckt einfach nur ein Denkfehler drin.

Falsch:
Code:
ls /tmp/*.rar | /root/extract.sh
Richtig:
Code:
ls /tmp/*.rar | xargs /root/extract.sh
Dasselbe lässt sich aber auch viel einfacher ausdrücken
Code:
/root/extract.sh /tmp/*.rar
und ist wahrscheinlich nicht, was Du meinst, weil es eine andere Bedeutung hat. (Das funktioniert beides nur, wenn "/root/extract.sh" mehrere Dateinamen als Argumente akzeptiert.)
 
traffic schrieb:
Falsch:
Code:
ls /tmp/*.rar | /root/extract.sh
Richtig:
Code:
ls /tmp/*.rar | xargs /root/extract.sh
Dasselbe lässt sich aber auch viel einfacher ausdrücken
Code:
/root/extract.sh /tmp/*.rar
Das "Richtig" erfasst aber leider wieder keine Leerzeichen, also entweder "Dasselbe" nehmen oder
Code:
find /tmp -maxdepth 1 -iname "*.rar" | xargs -0 /root/extract.sh
Bei xargs empfiehlt sich auch immer -r dazu.
 
Statt "Richtig" hätte da einfach "anders" stehen sollen, es ist nämlich nicht nur wegen der Leerzeichen nicht richtig, sondern zusätzlich auch noch wegen des Falls, dass nicht unbedingt Dateien existieren müssen, die auf /tmp/*.rar passen.

Alle vorgeschlagenen Lösungen haben sind übrigens immer noch nicht richtig, weil sie nicht korrekt mit dem Fall umgehen, dass es neben regulären Dateien u.a. auch Verzeichnisse geben kann, die auf *.rar enden.

Bei einem typischerweise für jedermann schreibbaren Verzeichnis wie /tmp spielt das eine Rolle, weil angemeldete Benutzer das Skript dazu bringen können, anderen Dinge zu tun, als es tun soll, indem sie einfach so ein Verzeichnis erstellen.

Sicherer Umgang mit temporären Dateien und für jedermann schreibbaren Verzeichnissen wäre also auch noch zu berücksichtigen.
 
Oben