Hallo Leute! Ich bin auf ein Problem mit cp gestossen, das ich nicht mit Hilfe von 'man cp' loesen konnte. Ich wollte alle Dateien meines Home-Verzeichnisses in ein anderes Verzeichnis, z.B. /home/sicher, sicherheitskopieren. Dazu nahm ich den Befehl 'cp -a /home/name/* /home/sicher/'. Dabei wurden jedoch keine unsichtbaren (.name) Dateien mitkopiert! Ich merkte das als KMail meine Mails nicht mehr anzeigen wollte, denn die Indexfiles ~/Mail/.Fach.index wurden nicht mitkopiert! Ich habe leider keine Schalterkombination gefunden, um *Alles* kopieren zu koennen :( Geht dies mit cp ueberhaupt? Gruss Florian
Hallo Florian, * Florian Evers schrieb am 07.Jun.2001:
Ich bin auf ein Problem mit cp gestossen, das ich nicht mit Hilfe von 'man cp' loesen konnte.
Kein Wunder, denn es hat unmittelbar auch nichts mit cp zu tun.
Ich wollte alle Dateien meines Home-Verzeichnisses in ein anderes Verzeichnis, z.B. /home/sicher, sicherheitskopieren. Dazu nahm ich den Befehl 'cp -a /home/name/* /home/sicher/'. Dabei
So, was sieht cp von diesem Befehl? Die *shell* interpretiert diese Zeile zuerst und macht daraus: cp -a /home/name/datei1 /home/name/datei2 .... /home/sicher Wobei datei1, datei2, ... für Deine Dateien steht, die in Deiner /home/name stehen. cp bekommt von dem * nichts mit. cp weiß nur, daß er all diese Dateien nach dem letzten Eintrag, hier /home/sicher kopieren soll. Es ist für cp völlig gleich, ob Du es so eingibst, wie Du es geschrieben hast, also mit * oder ob Du alle Dateien einzeln aufführst. cp hat keinerlei Möglichkeiten da zu unterscheiden.
wurden jedoch keine unsichtbaren (.name) Dateien mitkopiert!
Klar, denn die Shell ersetzt * nicht durch Dateien, die mit . beginnen. Völlig egal, ob der Befehl cp, ls oder sonstwie heißt.
Ich habe leider keine Schalterkombination gefunden, um *Alles* kopieren zu koennen :( Geht dies mit cp ueberhaupt?
Hat wie gesagt nichts mit cp zu tun. Möglich wäre cp -a /home/name/* /home/name/.??* /home/sicher dann bekommst Du aber eine Fehlermeldung, wenn es keine Dateien gibt, die mit . anfangen. Die beiden ? sind dafür, daß . und .. nicht mitkopiert werden. Wenn Du dann eine Datei hast, die z.B .a heißt, so wird auch diese nicht mitkopiert. Aber meist sind Dateinamen länger als einen Buchstaben. Kann man natürlich auch noch mitnehmen: cp -a /home/name/* /home/name/.??* /home/name/.[^.] /home/sicher aber wie gesagt, wenn das nicht existiert, gibt es Fehlermeldungen, denn dann wird z.B /home/name.[^.] von der shell uninterpretiert nach cp weitergegeben und das existiert wohl nicht. Bernd -- Homepages von deutschsprachigen Linux-Gurus: Kristian Köhntopp: http://www.koehntopp.de/kris/artikel/ Sven Guckes: http://www.math.fu-berlin.de/~guckes/sven Robin S Socha: http://socha.net/index2.html |Zufallssignatur 10
Bernd Brodesser schrieb am Don, 07 Jun 2001:
Hallo Florian,
* Florian Evers schrieb am 07.Jun.2001:
Ich bin auf ein Problem mit cp gestossen, das ich nicht mit Hilfe von 'man cp' loesen konnte.
Kein Wunder, denn es hat unmittelbar auch nichts mit cp zu tun.
Ich wollte alle Dateien meines Home-Verzeichnisses in ein anderes Verzeichnis, z.B. /home/sicher, sicherheitskopieren. Dazu nahm ich den Befehl 'cp -a /home/name/* /home/sicher/'. Dabei
So, was sieht cp von diesem Befehl? Die *shell* interpretiert diese Zeile zuerst und macht daraus: cp -a /home/name/datei1 /home/name/datei2 .... /home/sicher
Wobei datei1, datei2, ... für Deine Dateien steht, die in Deiner /home/name stehen. cp bekommt von dem * nichts mit. cp weiß nur, daß er all diese Dateien nach dem letzten Eintrag, hier /home/sicher kopieren soll. Es ist für cp völlig gleich, ob Du es so eingibst, wie Du es geschrieben hast, also mit * oder ob Du alle Dateien einzeln aufführst. cp hat keinerlei Möglichkeiten da zu unterscheiden.
wurden jedoch keine unsichtbaren (.name) Dateien mitkopiert!
Klar, denn die Shell ersetzt * nicht durch Dateien, die mit . beginnen. Völlig egal, ob der Befehl cp, ls oder sonstwie heißt.
Ich habe leider keine Schalterkombination gefunden, um *Alles* kopieren zu koennen :( Geht dies mit cp ueberhaupt?
Hat wie gesagt nichts mit cp zu tun. Möglich wäre
cp -a /home/name/* /home/name/.??* /home/sicher
dann bekommst Du aber eine Fehlermeldung, wenn es keine Dateien gibt, die mit . anfangen. Die beiden ? sind dafür, daß . und .. nicht mitkopiert werden. Wenn Du dann eine Datei hast, die z.B .a heißt, so wird auch diese nicht mitkopiert. Aber meist sind Dateinamen länger als einen Buchstaben. Kann man natürlich auch noch mitnehmen:
cp -a /home/name/* /home/name/.??* /home/name/.[^.] /home/sicher
aber wie gesagt, wenn das nicht existiert, gibt es Fehlermeldungen, denn dann wird z.B /home/name.[^.] von der shell uninterpretiert nach cp weitergegeben und das existiert wohl nicht.
Also, bei mir habe ich in der crontab zur taeglichen Sicherung meiner Dateien 'cp -fR /home/* /backup' stehen. Funktioniert einwandfrei auch mit unsichtbaren Dateien und Verzeichnissen. HTH Manfred -- Registered Linux-User #216556 http://counter.li.org./ ******************************************* In a World without Walls and Fences, who needs Windows and Gates? *******************************************
On Don, Jun 07, 2001 at 09:04:32 +0200, Manfred Misch wrote: [50 Zeilen unnötiges Fullquote umweltfreundlich entsorgt]
Also, bei mir habe ich in der crontab zur taeglichen Sicherung meiner Dateien 'cp -fR /home/* /backup' stehen. Funktioniert einwandfrei auch mit unsichtbaren Dateien und Verzeichnissen.
Ja, aus einem einfachen Grund: Direkt unter /home liegen i. d. R. keine .dateien. Mach mal ein:
/home/.datei und suche diese Datei in /backup. Du wirst sie nicht finden.
Es ist ein gängiger Weg, statt cp /home/benutzer/* /home/sicher ein cp -r /home/benutzer /home/sicher anzugeben, das funktioniert aber nur dann wie vorgesehen, wenn /home/sicher noch nicht existiert. Sonst legt er ein Verzeichnis /home/sicher/benutzer an, was nicht immer so gewünscht ist. In Deinem Fall legt der cp ja auch für jedes unter /home befindliche Verzeichnis ein gleichnamiges unter /backup an, oder? Jan
Am Donnerstag, 7. Juni 2001 21:32 schrieb Jan Trippler:
Es ist ein gängiger Weg, statt cp /home/benutzer/* /home/sicher ein cp -r /home/benutzer /home/sicher anzugeben, das funktioniert aber nur dann wie vorgesehen, wenn /home/sicher noch nicht existiert. Sonst legt er ein Verzeichnis /home/sicher/benutzer an, was nicht immer so gewünscht ist.
Hallo Leute, Danke fuer Eure Hilfe! So wie oben angegeben hat jetzt alles wie gewollt funktioniert. Das die Shell die Kommandozeile erstmal selbst ersetzt hatte ich schon mal gehoert, jedoch waere ich hierbei nie drauf gekommen :) Ist halt kein (4)Dos, ist halt Linux :) Gruesse, Florian
Jan Trippler
On Don, Jun 07, 2001 at 09:04:32 +0200, Manfred Misch wrote: [50 Zeilen unnötiges Fullquote umweltfreundlich entsorgt]
Sorry, aber ich dachte es wäre dann alles so zusammenhanglos ;-)
Ja, aus einem einfachen Grund: Direkt unter /home liegen i. d. R. keine .dateien. Mach mal ein:
/home/.datei und suche diese Datei in /backup. Du wirst sie nicht finden.
So isses, aber ich will ja auch alle Unterverzeichnisse sichern. Und das geht so nun mal einfacher als cp /home/unterverz1 /home/unterverz2 ... /backup
In Deinem Fall legt der cp ja auch für jedes unter /home befindliche Verzeichnis ein gleichnamiges unter /backup an, oder?
So isses wieder und so isses gewollt. cu Manfred
* Manfred Misch schrieb am 07.Jun.2001:
Also, bei mir habe ich in der crontab zur taeglichen Sicherung meiner Dateien 'cp -fR /home/* /backup' stehen. Funktioniert einwandfrei auch mit unsichtbaren Dateien und Verzeichnissen.
In der /home gibt es ja normalerweise auch gar keine Dateien die mit einem . beginnen. Die Dateien, die innerhalb der Homeverzeichnisse stehen, dafür ist ja auch cp verantwortlich. Und cp kopiert dann auch alle Dateien, die mit einem . beginnen. Nochmal: Wenn Du cp -fR /home/* /backup sagst, dann macht die shell daraus ein cp -fR /home/manfred /home/user1 /home/user2 /home/testuser /backup wenn ich mal davon ausgehe, daß Du die User manfred, user1, user2 und testuser in Deinem Homeverzeichnis hast. Leg mal eine Datei .test in Deiner /home an. Ich garantiere Dir, daß die nicht mitkopiert wird. Was mit den Dateien innerhalb von /home/manfred passiert, die wegen der Option -R mitkopiert werden, daß steht auf ein ganz anderem Blatt. cp ruft ja nicht mehr die shell auf. So wird dann auch /home/manfred/.profile mitkopiert. PS: Der richtige Ort für /backup wäre irgendwo unter /var oder meinetwegen unter /usr/local. Bernd
Bernd Brodesser
Nochmal: Wenn Du cp -fR /home/* /backup sagst, dann macht die shell daraus ein
cp -fR /home/manfred /home/user1 /home/user2 /home/testuser /backup
Genau das ist gewollt.
wenn ich mal davon ausgehe, daß Du die User manfred, user1, user2 und testuser in Deinem Homeverzeichnis hast. Leg mal eine Datei .test in Deiner /home an. Ich garantiere Dir, daß die nicht mitkopiert wird.
Da soll ja keiner was ablegen ;-)
PS: Der richtige Ort für /backup wäre irgendwo unter /var oder meinetwegen unter /usr/local.
Warum? Das musst Du mir schon etwas genauer erklären, wegen mir auch per PM, wenn das den Rahmen hier sprengt. /backup ist das einzige Verzeichnis auf meiner zweiten, alten, kleinen Festplatte, die nur noch zum sichern solcher Daten dient und ist IMHO damit besser geeignet als irgendein Unterverzeichnis in /var oder /usr. cu Manfred
* Manfred Misch schrieb am 08.Jun.2001:
Bernd Brodesser schrieb am Donnerstag, 7. Juni 2001 22:09
Nochmal: Wenn Du cp -fR /home/* /backup sagst, dann macht die shell daraus ein
cp -fR /home/manfred /home/user1 /home/user2 /home/testuser /backup
Genau das ist gewollt.
Na klar, aber es ging doch darum, daß cp * keine Dateien mit einem . am Anfang mitnimmt.
PS: Der richtige Ort für /backup wäre irgendwo unter /var oder meinetwegen unter /usr/local.
Warum? Das musst Du mir schon etwas genauer erklären, wegen mir auch per PM, wenn das den Rahmen hier sprengt. /backup ist das einzige Verzeichnis auf meiner zweiten, alten, kleinen Festplatte, die nur noch zum sichern solcher Daten dient und ist IMHO damit besser geeignet als irgendein Unterverzeichnis in /var oder /usr.
Du kanst auch /usr/local/backup oder /var/backup als eigene Partition einbinden. Bernd -- Hast Du bei Problemen schon in der SuSE-Support-Datenbank (SDB) nachgesehen? Auf Deinem Rechner: http://localhost/doc/sdb/de/html/index.html | mit Apache: http://localhost/doc/sdb/de/html/key_form.html | Zufalls- Tagesaktuell bei SuSE: http://sdb.suse.de/sdb/de/html/index.html | signatur 2
On Don, Jun 07, 2001 at 07:15:38 +0200, Florian Evers wrote:
Ich wollte alle Dateien meines Home-Verzeichnisses in ein anderes Verzeichnis, z.B. /home/sicher, sicherheitskopieren. Dazu nahm ich den Befehl 'cp -a /home/name/* /home/sicher/'. Dabei wurden jedoch keine unsichtbaren (.name) Dateien mitkopiert! Ich merkte das als KMail meine Mails nicht mehr anzeigen wollte, denn die Indexfiles ~/Mail/.Fach.index wurden nicht mitkopiert!
Das ist kein Problem des cp, sondern der Shell. Wenn Du cp * zielverzeichnis angibst, dann expandiert die Shell den * zu allen Dateinamen, die _nicht_ mit einem Punkt beginnen. Mach also zusätzlich zum o. g. cp ein cp .[^.]* zielverzeichnis Da erwischst Du aber nicht die Dateien, die mit _zwei_ Punkten beginnen. Eleganter ist hier der find: find . -type f -maxdepth 1 -exec cp {} zielverzeichnis \; Auch möglich - Eine for-Schleife: for i in `ls -a`; do test -f $i && cp $i zielverzeichnis done Weitere Verfahren: cpio, tar ... (?) Jan
Am Donnerstag, 7. Juni 2001 19:15 schrieb Florian Evers:
Dazu nahm ich den Befehl 'cp -a /home/name/* /home/sicher/'. Dabei wurden jedoch keine unsichtbaren (.name) Dateien mitkopiert!
Versuch' es mit cp <pfad>/.* <zielpfad> Die manpage von cp sagt hierzu nichts, weil es sich um einen generellen Shell-Mechanismus handelt. - Matthias
On Don, Jun 07, 2001 at 08:35:22 +0200, Matthias Kleine wrote:
Am Donnerstag, 7. Juni 2001 19:15 schrieb Florian Evers:
Dazu nahm ich den Befehl 'cp -a /home/name/* /home/sicher/'. Dabei wurden jedoch keine unsichtbaren (.name) Dateien mitkopiert!
Versuch' es mit cp <pfad>/.* <zielpfad>
Das gibt Ärger, weil er . und .. mitkopieren soll. Jan
* Matthias Kleine schrieb am 08.Jun.2001:
Jan Trippler wrote:
Versuch' es mit cp <pfad>/.* <zielpfad>
Das gibt Ärger, weil er . und .. mitkopieren soll.
Nein, denn . und .. sind Verzeichnisse, die ohne Angabe von "-R" ohnehin übersprungen werden. No problem.
Stimmt, Du hast Recht, aber das ist eine Eigenheit von GNU. Findest Du bei andere Unice nicht. Bernd -- Probleme mit dem Drucker? Schon die Druckercheckliste beachtet? http://localhost/doc/sdb/de/html/drucker-howto.html | Auch lesenswert: Oder schon das Drucker-HOWTO gelesen? | man lpr file://usr/shar/doc/howto/de/DE-Drucker-HOWTO.txt.gz | Zufallssignatur 3
On Fre, Jun 08, 2001 at 06:38:22 +0200, Bernd Brodesser wrote:
* Matthias Kleine schrieb am 08.Jun.2001:
Jan Trippler wrote:
Versuch' es mit cp <pfad>/.* <zielpfad>
Das gibt Ärger, weil er . und .. mitkopieren soll.
Nein, denn . und .. sind Verzeichnisse, die ohne Angabe von "-R" ohnehin übersprungen werden. No problem.
Stimmt, Du hast Recht, aber das ist eine Eigenheit von GNU. Findest Du bei andere Unice nicht.
Das meinte ich auch nicht. Es ist einfach unsauber und der cp gibt einen Fehler aus und - was noch schlimmer ist - im Returncode zurück. Wenn ich das so in einem Skript benutze, dann ist das ein klassischer Fall von Programmfehler, der eigentlich keiner ist. Ich tendiere eigentlich meist dazu, Befehle so abzusetzen, dass ein Fehler (Meldung oder Returncode) genau dann kommt, wenn es wirklich im Sinne des Programms / Skripts / Aufrufs ein Fehler _ist_, und das ist nun mal in Matthias' Beispiel nicht der Fall. Ich sehe da schon ein Problem ;-) Für alle zum Ausprobieren: $ mkdir a $ >a/.a $ cp a/.* /tmp cp: a/.: omitting directory cp: a/..: omitting directory $ echo $? 1 $ Jan
Am Freitag, 8. Juni 2001 22:23 schrieb Jan Trippler:
Das meinte ich auch nicht. Es ist einfach unsauber und der cp gibt einen Fehler aus und - was noch schlimmer ist - im Returncode zurück. Wenn ich das so in einem Skript benutze, dann ist das ein klassischer Fall von Programmfehler, der eigentlich keiner ist.
Die Tatsache war mir durchaus bewußt. Ich hatte sogar den von Jan angegebenen Test gemacht, da ich vermutet hatte, daß cp die Meldungen lediglich als Warning ausgibt und der Returncode dennoch 0 sei. Das Verhalten von cp überraschte mich, und ich finde es durchaus fraglich. Das Standardverhalten von cp besteht darin, Dateien zu kopieren. Will man Unterverzeichnisse mitkopieren, so ist die -r Option anzugeben. Es ist daher nicht ganz einzusehen, warum cp einen Fehlercode zurückgibt, wenn es sein Standardverhalten praktiziert. Zudem ist der Fehlercode völlig nichtssagend einfach "1", so daß er auch in Skripten nicht von großem Wert ist, da auch dutzende anderer Fehler Ursache sein könnten. Ich kann also kein Skript schreiben, den Fehlercode prüfen und sagen: "Aha, es sind also Unterverzeichnisse vorhanden, ich gehe in den else case." Ich muß beim Schreiben des Skriptes entscheiden, ob ich nur Dateien oder auch Unterverzeichnisse kopieren will. Der Fehlercode ist hier nutzlos. Ich werde kommende Woche mal diverse andere Unices abklappern und dort den cp befragen. Wenn diese sich identisch verhalten, geb' ich gerne nach.
Ich tendiere eigentlich meist dazu, Befehle so abzusetzen, dass ein Fehler (Meldung oder Returncode) genau dann kommt, wenn es wirklich im Sinne des Programms / Skripts / Aufrufs ein Fehler _ist_
Frommer Wunsch. Vor allem bei der täglichen Arbeit. Wenn Du das wirklich durchziehst, Hut ab. Ich tendiere eher zu trial & error. - Matthias
On Sam, Jun 09, 2001 at 03:36:55 +0200, Matthias Kleine wrote: [cp-Fehler bei . und ..]
Das Standardverhalten von cp besteht darin, Dateien zu kopieren. Will man Unterverzeichnisse mitkopieren, so ist die -r Option anzugeben. Es ist daher nicht ganz einzusehen, warum cp einen Fehlercode zurückgibt, wenn es sein Standardverhalten praktiziert. Zudem ist der Fehlercode völlig nichtssagend einfach "1", so daß er auch in Skripten nicht von großem Wert ist, da auch dutzende anderer Fehler Ursache sein könnten. Ich kann also kein Skript schreiben, den Fehlercode prüfen und sagen: "Aha, es sind also Unterverzeichnisse vorhanden, ich gehe in den else case." Ich muß beim Schreiben des Skriptes entscheiden, ob ich nur Dateien oder auch Unterverzeichnisse kopieren will. Der Fehlercode ist hier nutzlos. Ich werde kommende Woche mal diverse andere Unices abklappern und dort den cp befragen. Wenn diese sich identisch verhalten, geb' ich gerne nach.
Diese Argumentation verstehe ich nicht. Wenn ich den cp anwende, dann sollte ich mir vorher im Klaren darüber sein, was ich überhaupt will (wie bei jedem anderen Befehl auch). _Wenn_ rekursiv kopiert werden soll, dann startet man cp von vornherein mit der -r Option, wenn nicht, dann ist es nur logisch, dass cp einen Fehler meldet, wenn er auf ein Verzeichnis trifft. Was ist daran fraglich? Eine andere Sacche ist der Returncode 1: _Nichts_sagend ist er nicht - er signalisiert einen Fehler. Weitere Informationen muss man sich in diesem Fall (wie übrigens bei vielen anderen Kommandos auch) aus den Fehlermeldungen holen. BTW: Unabhängig davon, wie andere *nixe reagieren (ich kann das aus der Erinnerung jetzt auch nicht sagen) - dieses Verhalten ist IMHO völlig korrekt. Wenn Du nämlich cp -r a/.* ziel startest, dann versucht er auch, . und .. mitzukopieren (was wegen Rekursion schiefläuft).
Ich tendiere eigentlich meist dazu, Befehle so abzusetzen, dass ein Fehler (Meldung oder Returncode) genau dann kommt, wenn es wirklich im Sinne des Programms / Skripts / Aufrufs ein Fehler _ist_
Frommer Wunsch. Vor allem bei der täglichen Arbeit. Wenn Du das wirklich durchziehst, Hut ab. Ich tendiere eher zu trial & error.
Es gelingt mir sicher auch nicht immer, aber alles andere ist IMHO - vorsichtig ausgedrückt - unsauberes Programmieren oder kurz gesagt Pfusch. Ich rede hier wohlgemerkt nicht vom schnellen Befehl in der Shell, aber spätestens bei einem Skript, welches ich mehr als einmal verwenden möchte, ist trial & error nur noch fahrlässig. Jan
Am Samstag, 9. Juni 2001 12:57 schrieb Jan Trippler: [Returncode sollte immer 0 sein]
Diese Argumentation verstehe ich nicht. Wenn ich den cp anwende, dann sollte ich mir vorher im Klaren darüber sein, was ich überhaupt will (wie bei jedem anderen Befehl auch).
Die Argumentation ist simpel: Ich verwende cp so, wie er arbeitet. Der Returncode ist nur in ganz wenigen Ausnahmefällen interessant. Wie sehr Du Dich verrenken mußt, wenn Du immer "korrekte" Kommandos absetzen willst, zeigt folgende kleine Aufgabe: Kopiere alle (sichtbaren) Dateien ohne Unterverzeichnisse von dir1 nach dir2. Wie lautet Dein Kommando? cp dir1/* dir2 führt zu Returncode 1 bei vorhandenen Unterverzeichnissen in dir1. Wie willst Du das umgehen? Z.B. cp `find dir1 -maxdepth 1 -type f -name "*"` dir2 Returncode ist "0", aber wer arbeitet so? - Matthias
On Sam, Jun 09, 2001 at 01:52:59 +0200, Matthias Kleine wrote:
Am Samstag, 9. Juni 2001 12:57 schrieb Jan Trippler:
[Returncode sollte immer 0 sein]
Diese Argumentation verstehe ich nicht. Wenn ich den cp anwende, dann sollte ich mir vorher im Klaren darüber sein, was ich überhaupt will (wie bei jedem anderen Befehl auch).
Die Argumentation ist simpel: Ich verwende cp so, wie er arbeitet. Der Returncode ist nur in ganz wenigen Ausnahmefällen interessant. Wie sehr
Wie bitte? Sorry, dann unterscheiden sich unsere Arbeitsweisen aber ganz erheblich - für mich ist der Returncode fast immer interessant, vor allem dann, wenn vom Erfolg des vorherigen Kommandos das nachfolgende abhängt. Das ist in Skripts, die aus mehr als einer Anweisung bestehen, eigentlich recht häufig ;-) Ansonsten hätten sich die Entwickler von Programmiersprachen wohl kaum solche Mühe mit dem Error-Handling gegeben.
Du Dich verrenken mußt, wenn Du immer "korrekte" Kommandos absetzen willst, zeigt folgende kleine Aufgabe:
Kopiere alle (sichtbaren) Dateien ohne Unterverzeichnisse von dir1 nach dir2. Wie lautet Dein Kommando?
cp dir1/* dir2
führt zu Returncode 1 bei vorhandenen Unterverzeichnissen in dir1. Wie willst Du das umgehen? Z.B.
cp `find dir1 -maxdepth 1 -type f -name "*"` dir2
Returncode ist "0", aber wer arbeitet so?
In einer Shell mache ich das auch (bei überschaubarer Anzahl von potenziellen Fehlern) mit einem einfachen cp, in Skripts entweder mit dem find oder mit: for i in *; do; test -f $i && cp $i ziel; done oder anderen Mechanismen. Dann bin ich mir jedenfalls sicher, dass ein Fehler auch tatsächlich ein Fehler ist. Mir ist es viel zu viel Arbeit, mich nachher an die Auswertung von Fehlerlogs zu setzen, in denen 90% der Fehlermeldungen gar keine sind. Ich vermeide Fehler lieber im Vorfeld, als mich nachher (_jedes Mal_ nach Ausführung des Skripts) an eine fruchtlose Analyse vermeindlicher Fehler zu machen. Um bei Deinem Beispiel zu bleiben: Wie willst Du sicherstellen, dass tatsächlich _alle_ Dateien im Ziel angekommen sind? Mit Deiner Methode hast Du 2 Möglichkeiten: - Analyse der Fehlermeldungen - Vergleich von Quell- und Zielverzeichnis Ich frage einfach $? ab und weiss dann (zumindest mit erheblich höherer Wahrscheinlichkeit als Du), dass was fehlt. Wo ist dann der höhere Aufwand? Nochmal: Der alte Spruch *Vorbeugen ist besser als heilen* ist IMHO auch in der IT sehr oft zutreffend. Jan
Am Samstag, 9. Juni 2001 18:06 schrieb Jan Trippler:
Wie bitte? Sorry, dann unterscheiden sich unsere Arbeitsweisen aber ganz erheblich - für mich ist der Returncode fast immer interessant, vor allem dann, wenn vom Erfolg des vorherigen Kommandos das nachfolgende abhängt.
Du redest vom Skripten, ich rede vom täglichen Arbeiten auf der Shell. Wenn Du aus cp eine Wissenschaft machen willst, ist das Deine Sache. Ich bevorzuge es, die Ausgabe auf stderr zu lesen statt ? abzufragen.
for i in *; do; test -f $i && cp $i ziel;
Ich könnte ja jetzt weitermachen und Dich fragen, was hier passiert, wenn eine Datei nicht readable ist - dann würde sie schlichtweg (und ohne Fehlermeldung!) nicht mitkopiert. Ein einfaches "cp * ziel" hätte dann jedoch gemeldet cp: cannot open `filename' for reading: Keine Berechtigung Da hätte doch glatt die "sichere" Methode zum Datenverlust geführt. - Matthias
Am Samstag, 9. Juni 2001 19:08 schrieb Matthias Kleine:
for i in *; do; test -f $i && cp $i ziel;
Ich könnte ja jetzt weitermachen und Dich fragen, was hier passiert, wenn eine Datei nicht readable ist - dann würde sie schlichtweg (und ohne Fehlermeldung!) nicht mitkopiert.
Muß mich korrigieren, das führt freilich zu der selben Fehlermeldung wie ein einfaches cp - allerdings zu einem möglicherweise irritierenden Returncode "0". (Wenn man das überflüssige Semikolon entfernt.) - Matthias
On Sam, Jun 09, 2001 at 07:08:50 +0200, Matthias Kleine wrote:
Am Samstag, 9. Juni 2001 18:06 schrieb Jan Trippler:
Wie bitte? Sorry, dann unterscheiden sich unsere Arbeitsweisen aber ganz erheblich - für mich ist der Returncode fast immer interessant, vor allem dann, wenn vom Erfolg des vorherigen Kommandos das nachfolgende abhängt.
Du redest vom Skripten, ich rede vom täglichen Arbeiten auf der Shell. Wenn Du aus cp eine Wissenschaft machen willst, ist das Deine Sache. Ich bevorzuge es, die Ausgabe auf stderr zu lesen statt ? abzufragen.
Wenn Du den Abschnitt weiter unten in meiner Mail berücksichtigt hättest - genau das habe ich da auch geschrieben. Meine Aussage bezog sich auf Deine Aussage, der Returncode sei fast immer uninteressant (_ohne_ davon zu reden, dass Du die Shell meinst). Es wäre nett, wenn Du in Zukunft die Quotings mal im Zusammenhang mit meinen restlichen Aussagen (in der gleichen Mail getroffen) lässt.
for i in *; do; test -f $i && cp $i ziel;
Ich könnte ja jetzt weitermachen und Dich fragen, was hier passiert, wenn eine Datei nicht readable ist - dann würde sie schlichtweg (und ohne Fehlermeldung!) nicht mitkopiert. Ein einfaches "cp * ziel" hätte dann jedoch gemeldet
cp: cannot open `filename' for reading: Keine Berechtigung
man test ... -f file True if file exists and is a regular file ... Probe: $ >a $ chmod -r a $ test -f a && echo existiert existiert $
Da hätte doch glatt die "sichere" Methode zum Datenverlust geführt.
Siehe oben - ab und zu solltest Du auch mal testen, was Du behauptest. Jan Ich schlage vor, dass wir bei weiterem Klärungsbedarf (ich habe keinen mehr) per PM weitermachen - der Sarkasmus in Deinem letzten Satz zeigt mir, dass in diesem Thread wohl keine für die Liste nützlichen Infos mehr kommen.
Am Samstag, 9. Juni 2001 20:36 schrieb Jan Trippler:
Probe: $ >a $ chmod -r a $ test -f a && echo existiert existiert
Ersetze echo mit cp und prüfe den Rückgabecode. Wer reißt hier also Dinge aus dem Zusammenhang? Notfalls schau Dir zur Erinnerung das Subject an.
Siehe oben - ab und zu solltest Du auch mal testen, was Du behauptest.
Hast Du denn mal probiert, was passiert, wenn Du eine Datei ohne Leserechte cp'st? Offenbar nicht, sonst würdest Du nicht so arrogantes Zeug aus Deiner Mailbox lassen.
Ich schlage vor, dass wir bei weiterem Klärungsbedarf (ich habe keinen mehr) per PM weitermachen
Absichtliches Mißverstehen muß öffentlich geahndet werden. - Matthias
On Sam, Jun 09, 2001 at 10:03:48 +0200, Matthias Kleine wrote:
Am Samstag, 9. Juni 2001 20:36 schrieb Jan Trippler:
Probe: $ >a $ chmod -r a $ test -f a && echo existiert existiert
Ersetze echo mit cp und prüfe den Rückgabecode. Wer reißt hier also Dinge aus dem Zusammenhang? Notfalls schau Dir zur Erinnerung das Subject an.
Jawohl, Euer Gnaden:
$ >a
$ chmod -r a
$ test -f a && cp a /tmp
cp: a: Keine Berechtigung
$ echo $?
1
$
So what?
Damit auch Du den Zusammenhang mit dem Subject kapierst:
test -f $i && cp $i ziel cp: a: keine Berechtigung test $? -ne 0 && rc=1 done $ echo $rc 1 $ </Beispiel>
Der Übersicht halber in mehreren Zeilen geschrieben, kann (mit ; am Ende jedes Befehls) auch in eine Zeile. Natürlich kann statt rc=1 hier ein beliebiges Error-Management stattfinden, das bleibt dem geneigten Anwender überlassen (es kann z. B. auch entschieden werden, ob der cp weitermachen soll oder die Schleife per break beendet werden soll). Es muss nur - wenn mehrere Befehle folgen sollen - statt && die if - then - fi Konstruktion verwendet werden:
if test $? -ne 0; then do_something fi
Siehe oben - ab und zu solltest Du auch mal testen, was Du behauptest.
Hast Du denn mal probiert, was passiert, wenn Du eine Datei ohne Leserechte cp'st? Offenbar nicht, sonst würdest Du nicht so arrogantes Zeug aus Deiner Mailbox lassen.
Siehe oben, Mister *ich_schreibe_zwar_Quark_aber_ich_habe_Recht*
Ich schlage vor, dass wir bei weiterem Klärungsbedarf (ich habe keinen mehr) per PM weitermachen
Absichtliches Mißverstehen muß öffentlich geahndet werden.
Woher nimmst Du die Frechheit, mir absichtliches Missverstehen zu unterstellen? _Ich_ lese jedenfalls die komplette Mail, bevor ich antworte. Bisher hast _Du_ in diesem Thread Zitate aus dem Zusammenhang gerissen und einen Haufen offensichtlich falsches Zeug geschrieben (was man mit geringer Mühe testen kann - siehe oben). Aber Du hast Recht, das muss öffentlich geahndet werden: *PLONK* Jan EOT
* Matthias Kleine schrieb am 10.Jun.2001:
Am Samstag, 9. Juni 2001 23:08 schrieb Jan Trippler:
*PLONK*
Er ist Führungskraft, er muß das machen.
Äh, Ihr beiden, habt Ihrs bald? Und das nur, weil der Eine cp im Terminal eingehackt meinte und der andere ein cp in einem ordentlichen Shellskript. Und sicherlich habt Ihr beide ein anderen Programmierstiel. Das liegt aber offensichtlich daran, daß Jan ehr größere umfangreiche Skripte schreibt und Matthias ehr kurze Ad hoc Skripte für den Augenblick. Wobei ich jetzt nicht gesagt habe, daß nicht auch Matthias größere Skripte schreibt und Jan nicht auch Ad hoc Skripte. Und sicherlich wird ein jeder zugeben, daß das was anderes ist. Ein Skript zu schreiben, daß man zumindest selber später noch verstehen sollte und das sich auch in ungewöhnlichen Situationen vernünftig verhalten soll, ist was anderes als ein Skript, daß jeder sowieso auch noch nach Jahren versteht, weil es aus nur wenigen kurzen Zeilen besteht, was aber gar nicht nötig wäre, da es nach Jahren nur dann noch besteht, wenn man es vergessen hat zu löschen. ;) Den Unterschied sieht man bei mir zumindest ganz deutlisch an der Verwendung von Variablen. Bei ordentlichen Skripten schreibe ich alles Mögliche in Variablen. So etwa den Namen einer Logdatei, temporärer Dateien, Nichtstandardbefehlen usw. Bei ad hoc Skripten schreibe ich alles direkt im Code. Da verwende ich noch nicht mal das obligatorische #! /bin/sh, warum auch? Und Kommentare gibt es da auch nicht. Und, ich kümmere mich nicht um Rückgabewerte. Mache auch keinen Syntaxcheck, weil ich davon ausgehe, daß ich alle notwendigen Argumente richtig eingebe. Davon kann man bei einem ordentlichen Skript sicherlich nicht ausgehen. Bernd
On Thu, Jun 07, 2001 at 07:15:38PM +0200, Florian Evers wrote:
Hallo Leute!
Ich bin auf ein Problem mit cp gestossen, das ich nicht mit Hilfe von 'man cp' loesen konnte.
Ich wollte alle Dateien meines Home-Verzeichnisses in ein anderes Verzeichnis, z.B. /home/sicher, sicherheitskopieren. Dazu nahm ich den Befehl 'cp -a /home/name/* /home/sicher/'. Dabei wurden jedoch keine unsichtbaren (.name) Dateien mitkopiert! Ich merkte das als KMail meine Mails nicht mehr anzeigen wollte, denn die Indexfiles ~/Mail/.Fach.index wurden nicht mitkopiert!
Ich habe leider keine Schalterkombination gefunden, um *Alles* kopieren zu koennen :( Geht dies mit cp ueberhaupt?
Hallo! Ich würde da schon eher auf eine Lösung mit Perl setzen: <schnipp> # hier steht bei aufruf 'scriptname quelldir zieldir' der suchpfad $dir=@ARGV[0]; # hier steht bei aufruf 'scriptname quelldir zieldir' der zielpfad $newdir=@ARGV[1]; # liest alle files, auch . und .., nach @allfiles opendir (DIR,$dir) || die "can't read dir"; @allfiles=readdir DIR; closedir DIR; # verwirft . shift @allfiles; # verwirft .. shift @allfiles; # jetzt stehen nur noch files im array # hier lese ich das array aus und verschiebe # die einzelnen dateien nach zielpfad foreach $file (@allfiles) { system ("/bin/mv $file $newdir"); } </schnipp> Die Perl-Funktion rename benötigt quelldateinamen und zieldateinamen mit kompletten pfad, daher nehme ich hier /bin/mv, und sie kann nicht über verschiedene Dateisystem kopieren. Mit bisschen mehr Aufwand, lassen sich damit auch ganze Verzeichnisblöcke kopieren. cu Udo -- Mail: samfire@gmx.de oder udo.neist@nikocity.de Hompage: http://home.tiscalinet.de/udoneist/
On Sam, Jun 09, 2001 at 01:18:14 +0200, Udo Neist wrote: [...]
Ich würde da schon eher auf eine Lösung mit Perl setzen:
Nimms mir nicht übel, aber statt eines Shell-Einzeilers ein Perlskript - das kommt mir etwas überzogen vor ;-)
# hier steht bei aufruf 'scriptname quelldir zieldir' der suchpfad $dir=@ARGV[0]; # hier steht bei aufruf 'scriptname quelldir zieldir' der zielpfad $newdir=@ARGV[1];
Fehlende Prüfung der Argumente. Im Beispiel besonders tödlich, weil das Zielverzeichnis nirgends geprüft wird. Wenn es nicht existiert, überschreibt jeder neue mv unten die verige Datei, die Originale sind weg.
# liest alle files, auch . und .., nach @allfiles opendir (DIR,$dir) || die "can't read dir"; @allfiles=readdir DIR; closedir DIR;
# verwirft . shift @allfiles; # verwirft .. shift @allfiles; # jetzt stehen nur noch files im array
Falsch! Jetzt stehen ausser . und .. alle Einträge unter $dir im Array. Das können Dateien, Verzeichnisse, Devices, Links ... sein.
# hier lese ich das array aus und verschiebe # die einzelnen dateien nach zielpfad foreach $file (@allfiles) { system ("/bin/mv $file $newdir"); }
Gefragt war eigentlich ein cp - Du verschiebst.
Die Perl-Funktion rename benötigt quelldateinamen und zieldateinamen mit kompletten pfad, daher nehme ich hier /bin/mv, und sie kann nicht über verschiedene Dateisystem kopieren.
Wie kommst Du darauf? Probier mal: $ >x $ perl -e ' rename ("x", "y"); ' BTW: mv kann Verzeichnisse auch nicht über Dateisystemgrenzen hinweg verschieben. Weder rename noch mv _kopieren_, sie benennen um / verschieben. Das fehlende Handling von Fehlern eingerechnet: Du tauschst mit diesem Perl-Skipt ein sauberes Arbeiten per cp (notfalls mit einem find gekoppelt) gegen ein sehr wackeliges Skript, dass auch nicht mehr Funktionalität bietet. Jan
Hallöchen [...] *Info* Ich habe die paar Zeilen nur aus dem Gedächtnis geschrieben, das da noch so einige Fehler drin sind, weiß ich. Und das mit mv anstatt cp habe ich zu spät bemerkt. Sollte ein Beispiel, keine Komplettlösung sein. Das 'mv' nicht über Dateisysteme verschieben kann, stimmt nicht. Es gibt nur die Einschränkungen des Dateisystems. Das Perl-'rename' das nicht kann, steht außerdem in den Büchern (wird dann auf mv verwiesen). Zudem ging es darum _alle_ Dateien zu kopieren, und das geht nicht mit 'cp *' und zusätzlichen 'cp .*'. cu Udo -- Mail: samfire@gmx.de oder udo.neist@nikocity.de Hompage: http://home.tiscalinet.de/udoneist/ chat: www.kilahu.de nick:weinbauer
On Sam, Jun 09, 2001 at 03:45:32 +0200, Udo Neist wrote: [...]
Ich habe die paar Zeilen nur aus dem Gedächtnis geschrieben, das da noch so einige Fehler drin sind, weiß ich. Und das mit mv anstatt cp habe ich zu spät bemerkt. Sollte ein Beispiel, keine Komplettlösung
Hat ja auch keiner was dagegen, das mache ich auch. Ich habe nur auf potenzielle Risiken hingewiesen, besonders deshalb, weil die fehlende Ziel-Prüfung sehr schnell zu Datenverlusten führen kann.
sein. Das 'mv' nicht über Dateisysteme verschieben kann, stimmt nicht. Es gibt nur die Einschränkungen des Dateisystems. Das
??? Ich habe geschrieben, dass mv Datei_verzeichnisse_ nicht über Dateisystemgrenzen hinweg verschieben kann. Probiers aus!
Perl-'rename' das nicht kann, steht außerdem in den Büchern (wird dann auf mv verwiesen).
Ja, kann ja durchaus sein - siehe oben. Der Unterschied ist ja schon aus dem Namen ersichtlich: rename = Umbenennen, mv = move = bewegen.
Zudem ging es darum _alle_ Dateien zu kopieren, und das geht nicht mit 'cp *' und zusätzlichen 'cp .*'.
Wie - das geht nicht? Natürlich geht das, hast Du die anderen Mails im Thread nicht gelesen? Sogar mit cp * und anschließendem cp .* (wenn man die Fehlermeldungen in Kauf nimmt). Jan P.S.: Ich habe den Eindruck, dass ich Dir mit meiner Antwort auf den Schlips getreten bin - das war keineswegs meine Absicht.
On Sat, Jun 09, 2001 at 05:45:55PM +0200, Jan Trippler wrote:
On Sam, Jun 09, 2001 at 03:45:32 +0200, Udo Neist wrote: [...]
Ich habe die paar Zeilen nur aus dem Gedächtnis geschrieben, das da noch so einige Fehler drin sind, weiß ich. Und das mit mv anstatt cp habe ich zu spät bemerkt. Sollte ein Beispiel, keine Komplettlösung
Hat ja auch keiner was dagegen, das mache ich auch. Ich habe nur auf potenzielle Risiken hingewiesen, besonders deshalb, weil die fehlende Ziel-Prüfung sehr schnell zu Datenverlusten führen kann.
Klar, das die fehlende Prüfung zu Schwierigkeiten führen kann, wenn man nicht weiß, was im Zielverzeichnis steht. In einem neuen Verzeichnis, das habe ich hier angenommen, da es eine Sicherheitskopie sein soll, ist das nicht ganz so schlimm.
sein. Das 'mv' nicht über Dateisysteme verschieben kann, stimmt nicht. Es gibt nur die Einschränkungen des Dateisystems. Das
??? Ich habe geschrieben, dass mv Datei_verzeichnisse_ nicht über Dateisystemgrenzen hinweg verschieben kann. Probiers aus!
Ups, hab ich tatsächlich überlesen.
Perl-'rename' das nicht kann, steht außerdem in den Büchern (wird dann auf mv verwiesen).
Ja, kann ja durchaus sein - siehe oben. Der Unterschied ist ja schon aus dem Namen ersichtlich: rename = Umbenennen, mv = move = bewegen.
Zudem ging es darum _alle_ Dateien zu kopieren, und das geht nicht mit 'cp *' und zusätzlichen 'cp .*'.
Wie - das geht nicht? Natürlich geht das, hast Du die anderen Mails im Thread nicht gelesen? Sogar mit cp * und anschließendem cp .* (wenn man die Fehlermeldungen in Kauf nimmt).
Wenn man die in Kauf nimmt sicher :-) Ich gehe meist davon aus, Fehlermeldungen zu vermeiden, auch wenn diese vielleicht nur Hinweise sind. Zumindest weisen Fehlermeldungen auf unsauberes Programmieren hin ;-)
Jan
P.S.: Ich habe den Eindruck, dass ich Dir mit meiner Antwort auf den Schlips getreten bin - das war keineswegs meine Absicht.
Ein klein wenig :-) Es ging ja nur ums Prinzip (siehe <schnipps></schnipps>). Das Script, woraus ich das habe, prüft auf Vorhandensein des Zielverzeichnisses, löscht die Daten, falls es existiert und erzeugt darin meine tar.bz2-Archive. Es ist zuverlässiger als mein altes Shell-Script. cu Udo -- Mail: samfire@gmx.de oder udo.neist@nikocity.de Hompage: http://home.tiscalinet.de/udoneist/ chat: www.kilahu.de nick:weinbauer
Hallo,
* Florian Evers
Ich habe leider keine Schalterkombination gefunden, um *Alles* kopieren zu koennen :( Geht dies mit cp ueberhaupt?
Also wenn Du den Kopiervorgang per Hand machst, unregelmaessig und nicht in ein Skript verpackt oder ueber Cron laufend, dann wuerde ich gnadenlos mit 'mc' den Midnight Commander zuecken, mit [Einfg] die zu kopierenden Sachen markieren und mit [F5] kopieren ;-) Viele Gruesse, Andreas -- Humor ist, wenn man trotzdem lacht. Kunst ist, wenn man trotzdem _nicht_ lacht. http://www.kolumne.ixy.de http://www.wortwaal.de/kneibskolumne/
participants (9)
-
Andreas Kneib -
Bernd Brodesser -
ESG-M.Misch＠t-online.de -
Florian Evers -
Jan.Trippler＠t-online.de -
Manfred Misch -
Matthias Kleine -
Matthias Kleine -
Udo Neist