Liste von Dateien eines Verzeichnisses abarbeiten

L

leok

Grünschnabel
Hallo,
stundenlang im Forum und sonstwo gesucht, aber immer noch kein Schritt weiter. Gestehe: bin blutiger Anfänger.
Die Lage: ich habe ein C-Programm, dass mir .buf Dateien dekodiert und in .txt (z.B. >test.txt) umwandeln kann. Die .buf Ausgangsdateien haben das Format 20061130_0521_abcd14_56636_ath.buf, wobei die ersten 13 Zeichen Jahr-Monat-Tag_Stunde-Minute darstellen. Der Rest der Dateibezeichnung ist willlkürlich. In einem Folder stehen mehrere hundert dieser Dateien, die eindeutig über die Zeitangabe im Filenamen ansprechbar sind. Ich will die Dateien nun automatisiert eine nach der anderen mittels des C-Programms dekodieren lassen und den output in .txt Dateien schreiben lassen, die 20061130_0521_abcd14_56636_ath usw. von der Eingabedatei übernehmen sollen.
Habt ihr dazu nen Tip, wo ich am besten anfangen kann??(
Vielen großen Dank!

PS: bin/bash
 
Wenn ich Dich richtig verstehe, sollte

Code: 
for i in [0-9]*; do cprogi ${i%.buf}; done

im Verzeichnis aufgerufen, in dem die Files liegen, funktionieren.
 
Yep, so kann man's auch auslegen. Das ist das Problem bei einer unvollständigen oder zweideutigen Beschreibung. ;)
 
Meine .sh-Datei mit den folgenden Befehlen, liegt im gleichen Ordner wie das Programm und die zu dekodierenden Dateien.

#!/bin/bash
for i in [0-9].buf ; do test_bufr i > ${i%buf}txt; done

Beim Ausführen der .sh kommt die Fehlermeldung "cannot read input file". Es wird eine [0-9].txt angelegt, die logischerweise nach dieser Fehlermeldung leer ist. Hab ich da was vergessen? Macht es evtl. einen Unterschied, ob vor der Datumsangabe noch Text steht (z.B. test_20061111_1111_...)?
Das C-Programm läuft mit einer Testdatei in diesem Verzeichnis fehlerfrei.

Vielen Dank schon mal!
 
Yep hast was vergessen, ich sag aber nicht was... ;)

edit: @supersucker - Arg, Spielverderber... ;)
 
Du hast da ein paar Zeichen vergessen....:D

Code: 
for i in [0-9]*.buf ; do cprogi i > ${i%buf}txt; done

vs.

Code: 
for i in [0-9].buf ; do test_bufr i > ${i%buf}txt; done

[0-9]*.buf

BTW: Die Umleitung ">" in eine neue Textdatei brauchst du nur wenn dein C-Programm das nicht von alleine macht.
 
supersucker schrieb:
Du hast da ein paar Zeichen vergessen....:D

Code: 
for i in [0-9]*.buf ; do cprogi i > ${i%buf}txt; done

vs.

Code: 
for i in [0-9].buf ; do test_bufr [b][COLOR="Red"]i[/COLOR][/b] > ${i%buf}txt; done

[0-9]*.buf

BTW: Die Umleitung ">" in eine neue Textdatei brauchst du nur wenn dein C-Programm das nicht von alleine macht.
Zum Vergrößern anklicken....

Fällt etwas auf?

Da fehlt ein $
Mein Vorschlag:
Code: 
for i in [0-9]*.buf ; do cprogi [b]$i[/b] > ${i/buf/txt}; done

Gruß Wolfgang
 
Zuletzt bearbeitet:
Hallo,
ich danke euch für eure Hilfe. Das kleine Puzzelchen war wohl aber nicht dafür verantwortlich. Werde weiterhin mit "cannot read input file"abgespeist :-(
Habe brav eure Zeil:
for i in [0-9]*.buf ; do test_bufr $i > ${i/buf/txtf}; done
eingetippt.
Habt ihr noch eine Idee, woran das liegen könnte?
 
Hallo
Erstens:
Hast du Leserechte für die Dateien?
Zweitens was gibt denn folgendes aus:
Code: 
for i in *buf; do echo "$i"; done
Eventuell haben die Dateien Leerzeichen im Namen?
Dann solltest du find mit xargs verwenden, was ohnehin bei sehr vielen Dateien angebracht ist.

Gruß Wolfgang
PS Man sollte übrigens möglichst immer Variablen quoten-> "$i" statt $i!
 
Zuletzt bearbeitet:
Dankschön,
Geprüft: Leerzeichen sind nicht im Dateinamen. Lese-und Schreibrechte habe ich alle.
Wenn ich deinen code eingebe, werden mir die Namen der zu dekodierenden Dateien ausgegeben
z.B.
pr1_amsu_20070131_2346_noaa17_23934_kan.buf
pr1_amsu_20070131_2346_noaa18_08765_ath.buf

??
 
leok schrieb:
Dankschön,
Geprüft: Leerzeichen sind nicht im Dateinamen. Lese-und Schreibrechte habe ich alle.
Wenn ich deinen code eingebe, werden mir die Namen der zu dekodierenden Dateien ausgegeben
z.B.
pr1_amsu_20070131_2346_noaa17_23934_kan.buf
pr1_amsu_20070131_2346_noaa18_08765_ath.buf

??
Zum Vergrößern anklicken....

Wenn du nun statt echo dein Programm ausführst und die Umleitung machst geht das nicht?
Wir reden hier aber nicht etwa von cygwin oder solch Hilfskrücken und von *nix-system oder?
Nur um das mal gleich auszuschließen.

Davon gehen wir hier im Unixboard eigentlich aus.

Gruß Wolfgang
 
Hallo,
danke, von cygwin habe ich genug;-)
Der Fehler lag im Detail (danke für den Hinweis mit dem echo).
Statt mit:
for i in [0-9]*.buf ; do test_bufr $i > ${i/buf/txtf}; done
funktioniert es mit:
for i in *buf; do test_bufr "$i"> ${i/buf/txtf}; done

Ich dank dir riesig!
Ciao
 
Die Hälfte des Threads hätte man sich sparen können, wenn man sich etwas Mühe bei der Problembeschreibung geben würde. Im ersten Beitrag steht:

... Die .buf Ausgangsdateien haben das Format 20061130_0521_abcd14_56636_ath.buf ...
Zum Vergrößern anklicken....

Jetzt schreibst Du, dass Sie so aussehen:

...
pr1_amsu_20070131_2346_noaa17_23934_kan.buf
...
Zum Vergrößern anklicken....

Sorry, aber sowas regt mich auf. Die Lösung lag also nicht am kleinen Detail der fehlenden Hochkommas.
 
Xanti,
Problembeschreibung scheint bei Vielen das Hauptproblem zu sein.

Du hast Recht, aber ohne dem $ hätte es auch nicht geklappt.

Gruß Wolfgang
 
Wolfgang schrieb:
Mein Vorschlag:
Code: 
for i in [0-9]*.buf ; do cprogi [b]$i[/b] > ${i/buf/txt}; done
Zum Vergrößern anklicken....

leok schrieb:
Habe brav eure Zeil:
for i in [0-9]*.buf ; do test_bufr $i > ${i/buf/txtf}; done
eingetippt.
Zum Vergrößern anklicken....
Auch wenn das nicht funktioniert hätte (aufgrund Deiner falschen bzw. ungenügenden Angabe), brav abgetippt hast Du vielleicht, jedoch falsch :D

Ich weiß nicht wie oder warum, aber Du hast ein f zuviel getippselt:
${i/buf/txtf}

Auch wenn das nicht darüber entscheidet, ob es deswegen funktioniert oder nicht, Du solltest etwas mehr darauf achten,
dass Du wenn nötig 3x drüber ließt und kontrollierst dass Du auch das abtippst, was Du haben willst.
Am besten machst Du das zukünftig per Copy&Paste und löschst das weg, was Du nicht brauchst...
Rechtschreibfehler hin oder her, in der Shell kannst Du Dir Tippfehler in den seltensten Fällen leisten :)
 
Anmelden, um zu antworten.

Neueste Themen

Zurück
Oben