Gibt es eine alternative zu echo um in einer mehrfach verschachtelten schleife Daten an stdout oder stderr zu senden? Echo hat in schleifen ja die Aufgabe Ergebnisse an die nächst höhere Instanz zu senden. Nun fehlt mir die Möglichkeit Fehler an stderr und Meldungen an stdout auszugeben.
aus einer schleife Daten an stdout und/oder stderr zu senden?
Anmeldungsdatum: Beiträge: 1928 |
|
||||||
Anmeldungsdatum: Beiträge: 11180 Wohnort: München |
echo schreibt einfach auf stdout. Mit Shell/Umleitungen kannst du es auch auf andere File-Descriptoren wie stderr schreiben lassen.
|
||||||
Projektleitung
Anmeldungsdatum: Beiträge: 12832 |
Nein, wie seahawk1986 ja bereits erklärt hat.
Zeig mal bitte Dein Beispiel. Was willst Du genau erreichen bzw. wo denkst Du hakt es? |
||||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 1928 |
Hier mein Script, es füllt mir regelmässig mein Mobiltelefon mit neuer zufällig ausgewählter Musik. Ich möchte gerne vor Zeile 20 eine Ausgabe einfügen, die mir sagt, welche Datei als Nächstes mit ffprobe bearbeitet wird, um einer vermutlich fehlerhaften Datei auf die Spur zu kommen. Gelegentlich werden Fehlermeldungen ausgegeben von denen ich aber nicht weiss welche Datei es betrifft. Ich tue mich etwas schwer damit eine oder mehrere Variablen innerhalb einer Schlaufe zu füllen und nach der Schlaufe weiter zu verwenden.
|
||||||
Projektleitung
Anmeldungsdatum: Beiträge: 12832 |
Etwas schwierig zu lesen, insbesondere, da die Einrückung etwas irreführend ist. Der Ich würde das ganze etwas anders angehen und mehr Pipelining sowie null-terminierte Dateinamen nutzen. Ungetestet
Ob das jetzt besser lesbar ist...? |
||||||
Anmeldungsdatum: Beiträge: 11180 Wohnort: München |
In dem Fall ist das ja eigentlich nicht unbedingt notwendig - man kann das Skript kürzen, wenn man die Arrays weglässt und mit find statt locate muss man auch nicht daran denken Mein Entwurf ist etwas kompakter als der von rklm (if-else Verzweigungen nehmen naturgemäß viel Platz weg) und meckert nur, wenn ffprobe beim Einlesen der Datei einen Fehler geworfen hat:
|
||||||
Projektleitung
Anmeldungsdatum: Beiträge: 12832 |
Das liegt aber auch daran, dass Du mehrere Ausdrücke ein eine Zeile packst und zwei Kommentare weggelassen hast. Wenn Du das so formatierst wie ich, kommen ungefähr sechs Zeilen hinzu. |
||||||
Anmeldungsdatum: Beiträge: 17552 Wohnort: Berlin |
Die allgemeine Popularität von find erfreut mich, aber ich sehe noch eine merkwürdige Lust am Nulltrennen, um die Ausgabe weiterzuverarbeiten. Damit ist verbunden, dass man weitere mögliche, nutzvolle find-Aktionen nicht mehr ausführen kann, in erster Linie denke ich da an -exec-Kommandos und in zweiter an die vielfältigen printf-Optionen, die zugegeben etwas spröde sind, und häufige manpage-Konsultationen beanspruchen, dann jedoch mit Funktionsreichtum glänzen. Tests umfangreicher Art kann man gut mit einem externen Script realisieren, das testet, was es so zu testen gibt, und je nach dem mit exit 1, 2, 3 einen Fehler zurückgibt, oder mit exit 0 oder stillschweigend Erfolg vermeldet. Da ich mit ffprobe nicht vertraut bin, und auf meinen Dateien auch keine raschen Einsichten gewann, hier ein Beispielscript das willkürlich Dateien aussortiert, wenn diese
Der Aufruf sieht dann etwa so aus:
und kann um weitere Tests ergänzt werden
Tests auf mehreren Dateien sind so natürlich nicht möglich, oder das Filtern der ersten 100 Dateien. Man könnte aber, wenn die Grundzahl der Dateien relativ stabil ist, sagen wir 10.000 Dateien, und man will 100 davon auswählen, mit einem Zufallsgenerator in 99 von 100 Fällen einen Fehler melden, und sich darauf verlassen, dass am Ende wohl 90-110 Dateien den Auswahlprozess überstehen oder doch 80-120, wenn man mit einer solchen Varianz klarkommt. |
||||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 1928 |
Danke für den Hinweis auf Zeile 33, das war noch ein Überbleibsel aus der Zeit als ich noch 200 verarbeitet habe. Mittlerweile habe ich festgestellt, dass ich bei weitem nicht mehr als 100 Stücke brauche. somit stört es mich auch nicht, wenn die Liste mal kürzer ist.
Auf den ersten Blick, Ja.
updatedb wird bei mir täglich einmal ausgeführt. Ausserdem habe ich kaum Fluktuationen im Bestand. Ich habe locate genommen weil es so schnell ist. selbst mit locate benütigt das script einiges an Zeit. Im übrigen auch der Grund weshalb ich in Zeile 14 die Zeit intensiven Operationen zusammengefasst und mit && ausgeführt habe.
Ich habe nicht wirklich das Bedürfnis das auf ein zweites File auszudehnen, ginge das auch mit einer Funktion?.
Wäre das denn schneller als locate mit sort und head? Bei Gelegenheit muss ich mir da noch ein paar Gedanken machen. |
||||||
Anmeldungsdatum: Beiträge: 17552 Wohnort: Berlin |
Mit Tricks vielleicht, aber find verarbeitet im -exec-Teil nur Programme, keine Bashfunktionen. Die Vorteile 2er Files ist sind, dass sie unabhängig voneinander geändert und anders kombiniert werden können. Zweitens können sie unabhängig voneinander getestet werden, also etwa wenn eine einzelne Datei nie in die Zufallsauswahl kommt, dann kannst Du den Test mit dieser einen Datei aufrufen und sehen, ob sie ausgefiltert wird. Drittens sind die Teile unabhängig voneinander zu verstehen. Die Sichtbarkeit der Variablen des anderen Scripts kann nicht mit der in diesem Script kollidieren, somit sind sie für sich leichter zu analysieren. Das aufrufende
Ich denke nicht. Ich weiß nicht wie rasch das Programm jetzt ist, wie viele wg. Genre etc. aussortiert werden und wie lange ffprobe läuft. Mal angenommen Du hast 5000 Files, von denen 3000 wg. Genre aussortiert werden und von den 2000 restlichen sollen 100 die Auswahl überstehen, also 1 von 20. Wenn jetzt ffprobe etwas dauert, dann kann man, statt 5000 Tests mit ffprobe zu machen, erst 5000 Tests mit Random machen, und dabei 250 Überlebende anpeilen. Von diesen würden bei ffprobe dann ca. 150 schreitern und etwa 100 blieben übrig. Das könnte also schon einen Zeitgewinn bringen, umso größer, je größer die Zahl zu verschmähender Dateien aus Losglück ist. Wie lange läuft denn das Programm? |
||||||
(Themenstarter)
Anmeldungsdatum: Beiträge: 1928 |
Ich habe jetzt leider nicht sonderlich viel Musse gross am Script herum zu basteln. Vor allem, weil ich ja ein funktionierendes habe. Dem Wunsch den ich initial geäussert habe konnte ich nachgehen und habe den Fehler behoben. Ich habe mein script mal wie gewünscht gemessen. Es braucht aktuell 22s der Ordner aus dem es die Musik zieht hat knapp 1000 mp3. Die Lieder sind in diverse Ordner verschachtelt was dafür sogt das kaum mehr als 3 files je ordner beieinander liegen. |