rekursives verschieben/löschen von mp3

A

AndiDreas

Mitglied
Thread Starter
Dabei seit
15.02.2005
Beiträge
39
Reaktionspunkte
0
hallo ich habe ein kleines problem.
ich habe eine seite mittels httrack gespiegelt...
nun möchte ich von diesen ganzen Dateien allerdings
nur die pdf und doc dateien haben. es ist doch sicher
mit den unix-kommandozeilentools folgendes zu machen:

was genau ich machen möchte, schreibe ich hier einfach mal
nieder...also

"durchsuche das verzeichniss /mirror und alle unterverzeichnisse
nach *.pdf und *.doc, kopiere die *.pdf Datei nach /archiv/pdf und
die *.doc Dateien nach /archiv/doc...lösche danach /mirror"...

:-/ hoffe das klingt nicht sooo kompliziert..

im prinzip: rekursivs durchstöbern eines verzeichnisses...
und wenn bestimmter dateityp gefunden, soll dieser in
ein verzeichniss kopiert werden...achja...gut wäre es
bei doppelten dateien, z.b. eine -1 -2 nummer anzuhängen
(ansonsten einfach überschreiben).

kann mir da jemand vielleicht helfen?

alleine mit den man pages für die befehle rm cp mv komme ich nicht
weiter leider :-/ bin da absoluter neuling
 
Also am besten nimmst du dafür den Befehl find.

PHP:
find /mirror -name *.pdf

Der Befehl liefert dir alle pdf-Dateien im Ordner /mirror (rekursiv). Mit der Option -exec kannst du eigene Kommandos ausführen, da kannst du z.b. ranhängen, dass er die Dateien in einen bestimmten Ordner kopieren soll. Wie das genau geht, musst du mal bitte selber schauen ;) Vielleicht reicht dir ja auch schon man find. Die Sache sollte dann zweimal laufen, einmal für .doc und einmal für .pdf. Das Löschen kannst du ja dann per Hand machen oder mit einem rm -r /mirror.

Dirk
 
syntax

vielen dank !
 
Fast richtig, aber nicht ganz ;)
Der '*' muss auf jeden Fall escaped werden, da er sonst bereits von der Shell ausgewertet wird und nicht von 'find'.

find /mirror -iname \*.pdf -exec mv {} /daten/ \;

verschiebt alle Dateien unterhalb von '/mirror', die auf '.pdf' oder '.PDF' enden, nach '/daten' (das Verzeichnis '/daten' sollte schon existieren).


HTH
 
  • Gefällt mir
Reaktionen: cpx
...

-exec utility [argument ...];
True if the program named utility returns a zero value as its
exit status. Optional arguments may be passed to the utility.
The expression must be terminated by a semicolon (``;''). If the
string ``{}'' appears anywhere in the utility name or the argu-
ments it is replaced by the pathname of the current file.
Utility will be executed from the directory from which find was
executed. Utility and arguments are not subject to the further
expansion of shell patterns and constructs.

wie ist dies denn zu verstehen ?

kennt vielleicht generell jemand eine gute seite, in denen es ne menge beispiele für shellskripte gibt ???? ich lese mich ständig durch welche man-files aber mir fehlt es einfach an ?erfahrung? oder erkenntniss :-D...
 
Mit 'exec utility' wird das Kommando <utility> ausgeführt; in diesem Fall 'mv'

Den "return value" benötigst Du diesmal nicht; damit könntest Du prüfen, ob das Kommando erfolgreich ausgeführt werden konnte (return value = 0 => Kommando erfolgreich ausgeführt).

Optionales Argument ist in diesem Fall '{}'.
Es wird durch den aktuell gefundenen Dateinamen mit Pfad ersetzt (also mit den Dateinamen die auf .pdf enden)

Der gesamte Ausdruck (also das Kommando mit evtl. Argumenten) muss mit ';' terminiert werden, damit 'find' weiss, wo er zu Ende ist (können ja danach noch weitere Ausdrücke kommen).
Der backslash vor ';' ist notwendig, da ';' sonst von der Shell ausgewertet wird und nicht an 'find' übergeben wird; die Folge wäre ein Syntax-fehler

HTH
 
Zuletzt bearbeitet:
suuuuuupi

danke,...so wie du das erklärst versteh ich das nun auch :-D

nun weiss ich auch wieso die geschweiften klammern da sind..das hatte mich zunächst verwirrt...feine sache....und vor allem schön schnell, wenn man nur weiss wie man mit den ganzen cmd-tools umgeht. danke danke danke. *verneig*
 
maceis schrieb:
Fast richtig, aber nicht ganz ;)

find /mirror -iname \*.pdf -exec mv {} /daten/ \;


Fast richtig, aber nicht ganz :)))

1. Quoten: mv "{}".
2. Vielleicht erstmal cp statt mv :))

3. Klugscheisserweise: Das geht in die Hose, wenn es z.B. einen Ordner(!) mit dem Namen "downloads.pdf" gibt. Daher noch: -type f

find /mirror -iname '*.pdf' -type f -exec cp "{}" /daten/ \;

...und wenn es nicht um "normale" Dateien geht, sondern um welche mit Ressource-Forks, dann empfehle ich dringendst die Installation des Developer-Pakets und die Benutzung von "MacMv / MacCp". Sonst kaputt. Naja - noch! In Tiger wird endlich, endlich, endlich ein HFS+-kompatibles cp/mv enthalten sein.


Ansonsten: Ich bin ja auch ein großer Terminal-Fan, aber das hätte man auch mit "Apfel-F" machen können ("Dateiname endet mit .pdf") und dann mit der Maus rumschubsen. Interessant wird das ganze mit Optionen wie "mindepth" und "maxdepth", oder wenn die Auswertung mehr erfordert als ein simples "mv".

exit,
ratti :)
 
ratti schrieb:
Fast richtig, aber nicht ganz :)))
Doch!
ratti schrieb:
1. Quoten: mv "{}".
Definitiv nicht notwendig. [STICHELMODE] Von Dir hätte ich erwartet, dass Du die man-page liest, ratti ;) [/STICHELMODE].
ratti schrieb:
2. Vielleicht erstmal cp statt mv :))
Möglich, aber ebenfalls nicht wirklich notwendig!
ratti schrieb:
3. Klugscheisserweise: Das geht in die Hose, wenn es z.B. einen Ordner(!) mit dem Namen "downloads.pdf" gibt.
Abhängig vom gewünschten Ergebnis; wenn der Ordner "downloads.pdf" verschoben werden soll, geht nix in die Hose ;).
Der Hinweis ist aber natürlich berechtigt.
ratti schrieb:
...und wenn es nicht um "normale" Dateien geht, sondern um welche mit Ressource-Forks, dann empfehle ich dringendst die Installation des Developer-Pakets und die Benutzung von "MacMv / MacCp". Sonst kaputt. Naja - noch! In Tiger wird endlich, endlich, endlich ein HFS+-kompatibles cp/mv enthalten sein.
...
Developer-Tools (rd. 1GB) nur deswegen installieren, ist overkill.
Dateien, die eine Resourcefork enthalten, kann man mit 'ditto --rsrc' problemlos kopieren.
Bei *.pdf- und *.doc-Dateien sollte es aber grundsätzlich keine Probleme geben.
 
Zuletzt bearbeitet:
(Quoten)
maceis schrieb:
Definitiv nicht notwendig. [STICHELMODE] Von Dir hätte ich erwartet, dass Du die man-page liest, ratti ;) [/STICHELMODE].

Nixda! :)

Genau das sagt meine manpage aber. Die ist allerdings nicht die vom Mac:


-exec command ;
Execute command; true if 0 status is returned. All following arguments to find are taken to be arguments to the command until an argument consisting of ‘;’ is encountered. The string ‘{}’ is replaced by the current file name being processed everywhere it occurs in the arguments to the command, not just in arguments where it is alone, as in some versions of find.
Both of these constructions might need to be escaped (with a ‘\’) or quoted to protect them from expansion by the shell. The command is executed in the starting directory.

...und "info 'Finding Files' gibt als Beispiel an:

find . -name '*.h' -exec diff -u '{}' /tmp/master ';'


Ich habe mir das Quoten angewöhnt. Es schadet an dieser Stelle nichts, und wenn man sowas macht wie

find -iname "*.dat" -exec rm "{}.*.tmp" \;

dann muss man wieder quoten. Deswegen quote ich immer.


Ich muss dir aber soweit recht geben, dass zumindest bei mir in der bash keine Probleme auftreten, wenn ich mir eine Datei "test test" oder "test*" anlege.



(type -f)
maceis schrieb:
Möglich, aber ebenfalls nicht wirklich notwendig!
Abhängig vom gewünschten Ergebnis; wenn der Ordner "downloads.pdf" verschoben werden soll, geht nix in die Hose ;).

Bei mv nicht, bei cp oder rm schon (nicht rekursiv per default), und abgesehen davon ist es schlechter Stil. Früher oder später geht sowas schief, und dann gibt es keinen Mülleimer.

...und ich würde nie im Leben ein find-exec auf mv oder rm loslassen, ohne nicht wenigstens einmal vorher "ls -lad '{}'" ausprobiert zu haben...


maceis schrieb:
Developer-Tools (rd. 1GB) nur deswegen installieren, ist overkill.
Dateien, die eine Resourcefork enthalten, kann man mit 'ditto --rsrc' problemlos kopieren.
Bei *.pdf- und *.doc-Dateien sollte es aber grundsätzlich keine Probleme geben.

Da installiere ich doch lieber die Developertools und verzichte auf den REST des Systems... :)
Du hast Rest. Ich installiere grundsätzlich überall die DevTools drauf - allein schon wegen SetFile und so.

Gruß,
Ratti
 
Zuletzt bearbeitet:
ratti schrieb:
(Quoten)
Nixda! :)
Genau das sagt meine manpage aber. Die ist allerdings nicht die vom Mac:
In https://www.macuser.de/forum/showpost.php?p=807151&postcount=5 hätteste lesen können
...
Utility and arguments are not subject to the further
expansion of shell patterns and constructs
.
ratti schrieb:
...Ich habe mir das Quoten angewöhnt. Es schadet an dieser Stelle nichts, ...
Es schadet nicht, aber zu behaupten, es wäre "nicht ganz" richtig, ist falsch.

ratti schrieb:
(type -f)
Bei mv nicht, bei cp oder rm schon (nicht rekursiv per default), und abgesehen davon ist es schlechter Stil. Früher oder später geht sowas schief, und dann gibt es keinen Mülleimer.
Na na na;
Das Kopieren schlägt dann fehl bzw. es werden im Zweifel eher zu wenig Daten gelöscht.
Es gehen aber keine Daten verloren; der Hinweis auf den fehlenden Papierkorb hinkt also ein bisschen.
Mal ganz abgesehen davon, dass hier ja 'mv' verwendet worden war.

Was daran schlechter Stil sein soll verstehe ich schon gleich gar nicht.
Was wäre denn dann Deiner Ansicht nach guter Stil?
Zuerst alle Dateien mit 'find -exec' kopieren und dann die Originale händisch löschen, aus Angst bei 'find' was falsch zu machen? kopfkratz
 
maceis schrieb:

In meiner manpage steht genau das Gegenteil. Siehe oben.
Es ist gut möglich, dass Apple ein anderes find implementiert hat, als ich hier habe. Das ist z.B. bei ps auch so.

maceis schrieb:
Es schadet nicht, aber zu behaupten, es wäre "nicht ganz" richtig, ist falsch.
Da hast du recht. Sorry - es war gut gemeint, dass der OP sich nicht mit * im Dateinamen irgendwas zerlegt. Das ist offensichtlich nicht der Fall. (Stichel: Ich würde aber trotzdem immer quoten :) )

maceis schrieb:
Das Kopieren schlägt dann fehl bzw. es werden im Zweifel eher zu wenig Daten gelöscht.

Und Fehlermeldungen ausgegeben, die "egal" sind, aber das fände ich nicht akzeptabel.

maceis schrieb:
Mal ganz abgesehen davon, dass hier ja 'mv' verwendet worden war.

Was daran schlechter Stil sein soll verstehe ich schon gleich gar nicht.
Was wäre denn dann Deiner Ansicht nach guter Stil?
Zuerst alle Dateien mit 'find -exec' kopieren und dann die Originale händisch löschen, aus Angst bei 'find' was falsch zu machen? kopfkratz

Jepp, das wäre in meinen Augen der bessere Stil. Das "händische" löschen beschränkt sich hier ja auf eine simple Komplettentsorgung des ganzen Ordners, der OP wollte ja nur aus seinem gespiegelten Ordner *.doc und *.pdf retten, der Rest kann weg.
Sollte das mal nicht so sein (das ist dann eher der Normalfall), braucht man ja nur den find-Befehl recyceln und ihn diesmal mit rm verwenden.

Mir sind mit find schon die bösesten Dinge passiert. Ein Tippfehler, und man werkelt in / statt ./ und solche Scherze.


Ich wollte eigentlich auch nicht deinen Tip madig machen.
Mit dem Quoten hatte ich unrecht.
Alles andere sind Erweiterungen nach dem Motto "Schöner Unixen mit dem kleinen Ratti":
Quote immer, statt zu überlegen, wo du musst.
Teste destruktive execs vorher mit ls.
Und, wo wir beim Thema sind: Im Zusammenhang mit "find" ist "-print0 | xargs -0" auch immer ein heisser Tip (Nein, in diesem Fall nicht, aber im Allgemeinen).

Gruß,
Ratti
 
Zuletzt bearbeitet von einem Moderator:
Hi

Fachlich habe ich nichts beizutragen, aber ihr zwei seid ein echtes Highlight in diesem Forum, weiter so, das hebt sich sich doch angenehm von vielen anderen Beiträgen ab.

Gruß vom guten alten W
 
ratti schrieb:
In meiner manpage steht genau das Gegenteil. Siehe oben.
Es ist gut möglich, dass Apple ein anderes find implementiert hat, als ich hier habe.
...
Apple hat das BSD find implementiert.
ratti schrieb:
Jepp, das wäre in meinen Augen der bessere Stil. Das "händische" löschen beschränkt sich hier ja auf eine simple Komplettentsorgung des ganzen Ordners,
...
Nein, wenn man mit '-type' und 'cp' arbeitet (wie von Dir vorgeschlagen) müssen alle Dateien händisch entsorgt werden. Das kann im Einzelfall nahezu unmöglich sein.
ratti schrieb:
Mir sind mit find schon die bösesten Dinge passiert. Ein Tippfehler, und man werkelt in / statt ./ und solche Scherze....
Das Unix-Motto kennst Du ja, oder? "Denn sie wissen, was sie tun." :D
Der Trick mit dem '-print' oder' -exec ls' ist natürlich ein guter Weg, das vorher herauszufinden.

ratti schrieb:
Ich wollte eigentlich auch nicht deinen Tip madig machen....
Hatte ich auch nicht so aufgefasst ;).
ratti schrieb:
...Quote immer, statt zu überlegen, wo du musst.
Oder wisse, was Du tust. Es gibt übrigens genügend Situationen, wo man durch überflüssiges escapen/quoten ein unerwünschtes Ergebnis erhält (Beispiele darfst Du Dir selbst ausdenken ;)).

Im Übrigens halte ich solche Diskussionen für sehr nützlich, weil dabei sozusagen im Vorbeigehen, Themen besprochen werden, von denen hoffentlich viele profitieren können.
 
Hallo nochmals, möchte nochmal meinen Dank aussprechen und mich Woulion anschließen. Vielleicht liegt es auch an der Gemeinder der "Mac-User", generell ist hier eine freundliche Stimmung. Hatte früher mal bereits in Linux-Foren die ein oder andere Frage und meist hieß es "read the fucking manual",...vielen lieben Dank....vor allem ermuntert dies einen doch sich ein wenig fortzubilden und den eigenen horizont shelltechnisch ein wenig zu erweitern, vor allem wenn man die Möglichkeiten sieht, die sich einem damit auftun.....wozu all diese kleinen freeware häppchen mit gui, wenn man dies nun alles alleine mit ein paar zeilen code bewältigen kann *danke danke
 
maceis schrieb:
Apple hat das BSD find implementiert.

Dann haben wir den Übeltäter.

Debian hat lt. englischer manpage das GNU-find implementiert. Ich hatte bisher die deutsche manpage angeguckt, und die schweigt sich diesbezüglich ganz aus.

maceis schrieb:
Nein, wenn man mit '-type' und 'cp' arbeitet (wie von Dir vorgeschlagen) müssen alle Dateien händisch entsorgt werden. Das kann im Einzelfall nahezu unmöglich sein.

In einem anderen Einzelfall würde ich das auch anders machen.

In diesem speziellen Einzelfall hat der OP eine Website gemirrort und will *.pdf rausholen, den Rest aber bloss entsorgen. Da würde ich mit find/cp in einen neuen Ordner arbeiten und hinterher den Ordner "www.example.com" komplett neben die Tonne treten.

Meine Denke dabei ist, dass man den Zielordner erst mal in Ruhe angucken kann, den Quellordner aber noch unverändert hat.

Beispiel für Fallstricke:

http://www.example.com/manual/german/manual.pdf
http://www.example.com/manual/english/manual.pdf

Ups. Erstes pdf überschreibt zweites pdf beim kopieren.


maceis schrieb:
Das Unix-Motto kennst Du ja, oder? "Denn sie wissen, was sie tun." :D
Der Trick mit dem '-print' oder' -exec ls' ist natürlich ein guter Weg, das vorher herauszufinden.

:) "Think before you type." :) Ja, bin ich ein grosser Freund von. Ich möchte aber ergänzen:

Narrensicheres Arbeiten ist der beste Weg, sich das Leben einfach zu machen.

Früher oder später sitzt man sonst doch wieder Sonntag Morgens im Auto auf dem Weg in die Firma. Die größten Katastrophen beginnen mit einem "nur mal eben schnell", und auf meinem Grabstein wird dereinst stehen "Er änderte ein Kleinigkeit". Bring dich nie in eine Lage, in der du unter Tränen "Je ne regrette rien" sagen musst. :)

So, die Chance zur Korrektur kann jetzt jemand anders nutzen - mein französisch ist nämlich deutlich schlechter als mein Scripting. :)

maceis schrieb:
Es gibt übrigens genügend Situationen, wo man durch überflüssiges escapen/quoten ein unerwünschtes Ergebnis erhält (Beispiele darfst Du Dir selbst ausdenken ;))

Schlag mich - aber ehrlich gesagt: Wenn mir die Shell über'n Kopf wächst, erledige ich das lieber mit einem 10zeiler in perl, mit einem Editor, Syntaxhighlighting und for-Schleife.

Gruß, Ratti
 
Zuletzt bearbeitet von einem Moderator:
Danke an euch für das Lob.

Das möchte ich aber kurz kommentieren:

AndiDreas schrieb:
Hatte früher mal bereits in Linux-Foren die ein oder andere Frage und meist hieß es "read the fucking manual"

Das hängt damit zusammen, dass die "Umgebung" anders ist. Wenn du und ich bei einem Bier sitzen, reden wir ja auch anders, als wenn wir gemeinsam an einer Podiumsdiskussion mit 800 Teilnehmern mitmachen.

Beispiel: Die letzte mir bekannte Teilnehmerzahl für die "Suse Linux Deutsch Mailinglist" ist schon einige Jahre alt und betrug 3500 aktive Leser, die diese Mails auch tatsächlich zugestellt bekommen.

Das bedeutet, das jede Mail einen ziemlichen Aufwand anstösst - sie geht an 3500 Menschen, und es gibt einen Mailserver, der das wuppen muss. Aus diesem Grund sind die Regeln, siehe Beispiel Podiumsdiskussion, einfach gezwungenermassen anders.
Man soll sich zum Beispiel nicht für Antworten bedanken - das Dankeschön geht an 3500 Leute. Man soll nichts fragen, was in der manpage steht - die Frage geht an 3500 Leute.

Der Community-Spirit geht da in Richtung "Hilf dir erstmal selbst. Wenn das nicht klappt, DANN helfen wir. Aber dann sag auch ganz exakt, WO und WAS klemmt." Und das betrifft dann eben auch Communities ausserhalb von Mailinglisten und Newsgroups - sind ja die gleichen Leute.


Die Mac-Community hat nunmal, bitte nicht böse sein, einen deutlich höheren Anteil an technischen Analphabeten, kommuniziert daher ganz anders, und muss gezwungenermassen andere Regeln aufstellen. Andere Länder, andere Sitten. Sozusagen.


Aber wenn es dich tröstet: Auch in einer Linux-Community soll man ein "RTFM" durchaus als persönliche Nachricht senden, nicht als öffentliche. :)

Gruß,
Ratti
 
verstehe.

hmmm, das stimmt allerdings...wenn man dies so betrachtet.

was meine fragen angeht, stelle ich diese meist sehr konkret, und beschreibe mein Problem lieber zwei, dreimal auf die ein oder andere weise...ich will ja schließlich das mir geholfen wird.

Auch frage ich meist dann, wenn ich es schon mit einem, meiner Meinung nach gerechtfertigten Aufwand einfach nicht schaffe....gibt ja auch welche, die einfach nur zu bequem sind...

anstatt Dankesreden zu halten, werde ich einfach versuchen, anderen zu helfen, mit dem was ich im laufe der zeit an problemen hatte, und die ich gelöst habe, durch EURE hilfe.

bzgl. RTFM...dies ist mir aber auch mehrmals in diversen IRC-Channels passiert, wo man mitunter gar einfach gekickt wird....manchmal denke ich, diese leute wurde scheinbar mit all ihrem wissen geboren *g...schließlich fängt jeder mal an,..klar sollte man ein gewisses grundverständniss und eine aufnahmefähigkeit verfügen, ausdauer und vor allem die bereitschaft zeit zu investieren...manchmal allerdings steht man vor einem problem "_das gelöst werden will_"...und man einfach nicht weiterkommt...da nützt einem RTFM nicht viel....ob das nun in deutsch, englisch latein oder sonstwas geschrieben ist....wenn man manche grundlegenden kenntnisse einfach nicht hat, wobei viele davon ja erst durch erfahrung kommen...und wie ich ab und an feststelle machen manchmal selbst erfahrene user was falsch, das dann aber fatale folgen haben kann....spiele ich einfach mal so ein wenig rum, schwupps hab ich den datensalat perfekt *FG...
 
AndiDreas schrieb:
"...und man einfach nicht weiterkommt...da nützt einem RTFM nicht viel....ob das nun in deutsch, englisch latein oder sonstwas geschrieben ist....

:)

Man sollte ja auch nur dann auf Manuals verweisen, wenn es sich dabei tatsächlich um die Problemlösung handelt, also zum Beispiel:

Q: "Wie kann ich bei 'ls' die Sortierung ändern?"
A: "RTFM"

Wenn man das FM tatsächlich mal R, dann steht das halt drin.


Eine Fehlkommunikation der Sorte "Kann mir jemand sagen, wo ich den Unterschied zwischen RAM und ROM nachlesen kann" - "RTFM!" ist dann aber wirklich ein sozialer Defekt. :-/

Sehr empfehlenswert, auf deutsch und gut geschrieben: Die Übersetzung von "How to ask smart questions" unter http://www.lugbz.org/documents/smart-questions_de.html

Das erklärt so manche Backpfeife im Nachhinein - von denen ich auch schon so manche kassiert habe. :)

Gruß,
Ratti
 
maceis schrieb:
find /mirror -iname \*.pdf -exec mv {} /daten/ \;
Sorry, das ich noch so spaet dazwischen gehe, aber "-exec" ist evil und das wollen wir nicht wirklich benutzen/ uns angewoehnen zu benutzen.

http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q="-exec" vs xargs

http://www.osxfaq.com/tips/unix-tricks/week49/tuesday.ws

Bei Dateisystemen und Abfragen von 5000 geht das vielleicht noch. Bei den FS die wir hier haben sind das vielleicht dann schon mal 200000 und dann liegt der Unterschied schnell im Stundenbereich.

Gruss von IceHouse
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben Unten