Immer nur die neueste Datei kopieren

[katze123]

Ich habe einen Ordner mit vielen Dateien und möchte, dass die neueste (die mit dem jüngsten Änderungsdatum) per Shellskript in einen bestimmten Zielordner kopiert wird. Die restlichen Dateien sollen weggelassen werden. Wie setz ich das in die Tat um?

[whisper]

Aus dem Stehgreif, ungetestet:

Code: Alles auswählen

ls -tr|tail -1

oder

Code: Alles auswählen

ls -t|head -1

Rest bekommst du hin?

[Meillo]

Aus dem Stehgreif, ungetestet:

Code: Alles auswählen

ls -tr|tail -1

oder

Code: Alles auswählen

ls -t|head -1

Nimm zweiteren Ansatz, weil der nur eine Zeile durch die Pipe schieben muss, waehrend bei ersterem alles durchgeschoben aber bis auf die letzte Zeile verworfen wird.

`head -1' und `tail -1' sind nicht (mehr) POSIX-kompatibel. Schreibe daher: `head -n 1' bzw. `tail -n 1'.

`head -n 17' kann immer durch `sed 17q' ersetzt werden. `head -n 1' sogar durch `sed q'. ... fuer den Fall, dass du gerne mehr unixy sein willst.

[katze123]

Danke für eure Antworten, ls -t|head -1 funktioniert wunderbar.

[breakthewall]

Generell ist es überhaupt nicht sicher noch ratsam den Output von ls zu parsen, aufgrund vielfacher Fallstricke bezüglich Datei -und Ordnernamen.

Daher eine Lösung mit find:

Code: Alles auswählen

find . -maxdepth 1 -type f -printf "%T@ %p\n" | sort -n | tail -n 1 | cut -d ' ' -f 2-

[uname]

Vielleicht auch so:

Code: Alles auswählen

find . -maxdepth 1 -type f -printf "%T@ %p\n"|awk '{if ($1>a){a=$1;b=$2}} END {print b}'

Nachtrag Punkt-Dateien:
Bei "ls" werden Punktdateien ignoriert. Du musst "ls -a" verwenden, um die "versteckten" Dateien einzubeziehen.

Bei dem find-Befehl sind sie standardmäßig enthalten. Um sie auszuschließen verwende:

Code: Alles auswählen

find . -maxdepth 1 -not -path '*/\.*' -type f -printf "%T@ %p\n"|awk '{if ($1>a){a=$1;b=$2}} END {print b}'

[whisper]

Aus dem Stehgreif, ungetestet:

Code: Alles auswählen

ls -tr|tail -1

oder

Code: Alles auswählen

ls -t|head -1

`head -1' und `tail -1' sind nicht (mehr) POSIX-kompatibel. Schreibe daher: `head -n 1' bzw. `tail -n 1'.

`head -n 17' kann immer durch `sed 17q' ersetzt werden. `head -n 1' sogar durch `sed q'. ... fuer den Fall, dass du gerne mehr unixy sein willst.

Aha, ja immer diese Neuerungen.
Aber meinen Dank an dich für die Alternativen!

[whisper]

Danke für eure Antworten, ls -t|head -1 funktioniert wunderbar.

Die anderen Lösungen sind natürlich auch richtig und besser, mein Ansatz war: User am Anfang der Scriptingkariere; nicht überfordern mit komplexeren als notwendigen Alternativen.

[Meillo]

Generell ist es überhaupt nicht sicher noch ratsam den Output von ls zu parsen, aufgrund vielfacher Fallstricke bezüglich Datei -und Ordnernamen.

Welche denn (die sich nicht auf `ls -l' beziehen)? Hast du dazu irgendwelche Referenzen?

Falls du auf Newlines in Dateinamen anspielen solltest, dann macht das deine Pipeline auch nicht besser.

[breakthewall]

Welche denn (die sich nicht auf `ls -l' beziehen)? Hast du dazu irgendwelche Referenzen?

http://mywiki.wooledge.org/ParsingLs
https://unix.stackexchange.com/question ... t-parse-ls

Falls du auf Newlines in Dateinamen anspielen solltest, dann macht das deine Pipeline auch nicht besser.

Doch tut sie. Denn für find spielt das alles keine Rolle, egal wie komplex oder exotisch der Input auch ist, da find selbst ist nicht diesen Problemen unterworfen ist. Da können Datei -und Ordnernamen auch Tabs, Spaces, Newlines und sonstigen Käse enthalten, selbst exotische Sonderzeichen, dass wird immer sauber aufgelistet und verarbeitet ohne dubiose Endergebnisse. Generell sollte man immer Shell-Globbing nutzen für Datei -und Ordnernamen, ganz egal um was es auch geht, oder universelle Programme wie find, die schon darauf getrimmt sind jeden Mist zu verarbeiten und kompatibel weiterzureichen. Und hier ist das Problem da insbesondere ls nicht garantieren kann, dass das was aufgelistet wird auch das ist was wirklich existiert und entsprechend weitergegeben wird. Das hängt stark vom Input ab, da ls nur ein sehr einfaches Programm ist und nicht für so etwas geschaffen wurde. Da muss man sehr aufpassen, gerade weil die Shell ein Interpreter ist, und das sehr abenteuerliche Folgen haben kann. Von daher sollte man lieber Lösungen nutzen, die auch Daten auf sichere Weise verarbeiten. Und da sind Programme wie find nun mal etwas ganz Feines. Man könnte natürlich auch gleich Python nutzen, und erschlägt damit all diese Probleme.

[Meillo]

Welche denn (die sich nicht auf `ls -l' beziehen)? Hast du dazu irgendwelche Referenzen?

http://mywiki.wooledge.org/ParsingLs
https://unix.stackexchange.com/question ... t-parse-ls

Danke, die sehen interessant und fundiert aus. Ich lese mir die gerne in Ruhe durch.

Falls du auf Newlines in Dateinamen anspielen solltest, dann macht das deine Pipeline auch nicht besser.

Doch tut sie.

Dann lege mal eine Datei mit Newline an und fuehre darauf deine find-Pipieline und die ls-Pipepine aus. Du wirst sehen, dass beide in gleicher Weise scheitern.

Alleine find(1) zu verwenden loest *nicht* einfach das Problem! Find(1) kann lediglich helfen manche Problem zu loesen, die man mit ls(1) nicht loesen kann.

Denn für find spielt das alles keine Rolle, egal wie komplex oder exotisch der Input auch ist, da find selbst ist nicht diesen Problemen unterworfen ist. Da können Datei -und Ordnernamen auch Tabs, Spaces, Newlines und sonstigen Käse enthalten, selbst exotische Sonderzeichen, dass wird immer sauber aufgelistet und verarbeitet ohne dubiose Endergebnisse.

Ich verstehe natuerlich schon was du meinst: Die internen Tests von find(1) funktionieren korrekt in all diesen Faellen. Aber sobald du die find-Ausgaben in eine Pipe schiebst, dann ist das Ergebnis gleich wie wenn die die Ausgaben von ls(1) in eine Pipe schiebst. Und die interne Funktion `-t' von ls(1) funktioniert halt ebenso korrekt wie die internen Funktionen von find(1).

Nur mit `-print0' kannst du korrekt durch die Pipe kommen und das bietet zwar find(1) aber nicht ls(1). Aber das verwendest du in deiner Pipeline ja gar nicht ... weil es natuerlich alle Tools in der Pipeline unterstuetzen muessten, was halt nicht der Fall ist.

[...] da ls nur ein sehr einfaches Programm ist und nicht für so etwas geschaffen wurde.

Fuer was wurde ls(1) nicht geschaffen? Dateien aufzulisten? Ha, *gerade* dafuer wurde es geschaffen und das kann es in perfekter Weise. Das Problem ist nicht ls(1), sondern dass man Newlines in Dateinamen hat. Es ist IMO eine der wenigen schlechten Entscheidungen der Unix-Entwickler gewesen, Newlines in Dateinamen zu erlauben, weil das seither einen ganzen Rattenschwanz an Haesslichkeiten hervorgebracht hat, ohne, dass man von den Newlines in Dateinamen irgendeinen Nutzen haette. Meine Meinung ist, dass man Scripte fuer diesen Fall nicht verkomplizieren sollte (dazu fuehrt es naemlich: zu einer Halbierung der Lesbarkeit der Scripte), weil Unix-Systeme keine Newlines in Dateinamen haben sollten, und wer sowas hat, soll selber schauen wie er damit zurecht kommt. Das ist halt meine Meinung ... die aber nur am Rande, denn oben Geschriebenes ist davon unabhaengig und sachlich.

Ich will nochmal unterstreichen, das Problem ist nicht ls(1). Deine Aussage ist mir zu pauschal und deine Loesung bietet eben nicht das Versprochene sondern bloss das Gleiche wie mit ls(1) in weniger lesbar. Nichts desto trotz schaetze ich deine Anmerkung in diesem Thread, denn es ist wichtig, sich mit solchen Fragen zu befassen.