Hallo Ich durchforste gerade die Doku zu find und tar und stehe vor einem Problem. Ich suche eine Möglichkeit tar beizubringen eine Dateiliste von stdin zu lesen. Etwa so: echo "filename1 filename2" | tar -cf archiv.tar --unbekannteOption So dass dann beide Dateien in dem Archiv sind. Oder kann tar nur mittels -T die Filenamen aus einem anderen File lesen? Das finde ich irgendwie unpraktisch. mfg Axel
Hallo, On Thu, 05 Jun 2003, Peter Wiersig wrote:
Axel Heinrici wrote:
Oder kann tar nur mittels -T die Filenamen aus einem anderen File lesen?
Noe, geht:
echo -e "file1\nfile2" | tar cf test.tar -T-
oder:
tar cf test.tar -T <( echo -e "file1\nfile2" )
Letzeres wird nicht klappen, da du dem -T nicht sagst, aus welcher Datei es lesen soll. | tar cf test.tar -T /dev/stdin wuerde aber auch gehen. Das '-' als Dateiname ist einfach ein Sonderfall (siehe info tar): ==== `--files-from=FILE NAME' `-T FILE NAME' Get names to extract or create from file FILE NAME. If you give a single dash as a file name for `--files-from', (i.e., you specify either `--files-from=-' or `-T -'), then the file names are read from standard input. ==== -dnh -- 7: DOS Denial Of Service (Kristian Köhntopp)
David Haller wrote:
On Thu, 05 Jun 2003, Peter Wiersig wrote:
tar cf test.tar -T <( echo -e "file1\nfile2" )
Letzeres wird nicht klappen, da du dem -T nicht sagst, aus welcher Datei es lesen soll.
Das macht die Shell. (Ausprobiert: Beide Fehlermeldungen sind die gleichen. ;) Vorteil von '<( )': Man kann es oefter als einmal benutzen. Peter
Hallo, On Thu, 05 Jun 2003, Peter Wiersig wrote:
David Haller wrote:
On Thu, 05 Jun 2003, Peter Wiersig wrote:
tar cf test.tar -T <( echo -e "file1\nfile2" )
Letzeres wird nicht klappen, da du dem -T nicht sagst, aus welcher Datei es lesen soll.
Das macht die Shell. (Ausprobiert: Beide Fehlermeldungen sind die gleichen. ;)
Vorteil von '<( )': Man kann es oefter als einmal benutzen.
*HUCH*[tm] *g* Also, selbst wenn das mit "normalen" Dateinamen klappt, robust ist das nicht... ==== dh@slarty[1]: /tmp/test3 (0)$ ls -b1 a\tb b\\tc c\nd dh@slarty[1]: /tmp/test3 (0)$ cat * a b b\tc c d ## -> Inhalt == Dateiname ;) dh@slarty[1]: /tmp/test3 (0)$ tar cv -f test.tar -T <(echo *) tar: Cannot add file a b b c c: No such file or directory tar: Cannot add file d: No such file or directory tar: Error exit delayed from previous errors dh@slarty[1]: /tmp/test3 (2)$ $ tar cv -f test.tar -T <(echo -e 'a\tb'; echo 'b\tc') a\tb tar: Cannot add file b c: No such file or directory tar: Error exit delayed from previous errors $ tar cv -f test.tar -T <(echo -e 'a\tb'; echo 'b\\tc') a\tb b\\tc ==== Mit dem '\n' kommt tar aber so net klar. Was meist besser klappt: ==== $ find . -type f -print0 | tar cv -f test.tar --null -T - ==== Wie's scheint hat aber find oder tar mit dem '\' Probleme: ==== $ find . -type f -print0 | tar cv -f test.tar --null -T - ./a\tb tar: Cannot add file ./b c: No such file or directory ./c\nd tar: Error exit delayed from previous errors ==== Man beachte aber: 'c\nd' wird mit eingepackt... Warum tar beim '\\t' net will versteh ich auch net. find macht jedenfalls das richtige: ==== $ find . -type f -print0 | od -tx1 0000000 2e 2f 61 09 62 00 2e 2f 62 5c 74 63 00 2e 2f 63 0000020 0a 64 00 2e 2f 74 65 73 74 2e 74 61 72 00 0000036 ==== Hm. Jan? Hast du ne Idee? Is mein Tar zu alt? ==== $ tar --version | head -1 tar (GNU tar) 1.12 ==== -dnh --
Gehörst du auch zu den Leuten, die Ironie erst erkennen, wenn sie ihnen ein Loch ins Knie bohrt und Goldfische drin züchtet? [Sebastian Posner in dasr]
On Fre, 06 Jun 2003 at 09:25 (+0200), David Haller wrote: Moin, [...]
Also, selbst wenn das mit "normalen" Dateinamen klappt, robust ist das nicht...
ACK
dh@slarty[1]: /tmp/test3 (0)$ ls -b1 a\tb b\\tc c\nd [...] Was meist besser klappt:
==== $ find . -type f -print0 | tar cv -f test.tar --null -T - ====
Wie's scheint hat aber find oder tar mit dem '\' Probleme:
==== $ find . -type f -print0 | tar cv -f test.tar --null -T - ./a\tb tar: Cannot add file ./b c: No such file or directory ./c\nd tar: Error exit delayed from previous errors ====
Man beachte aber: 'c\nd' wird mit eingepackt... Warum tar beim '\\t' net will versteh ich auch net. find macht jedenfalls das richtige:
IMHO stänkert die Shell da. Die Sonderbedeutung des Backslash als Entwerter wird ja nicht aufgehoben. Das sieht man auch daran, dass nur ein \ beim tar ankommt - das übliche Verhalten.
$ find . -type f -print0 | od -tx1 0000000 2e 2f 61 09 62 00 2e 2f 62 5c 74 63 00 2e 2f 63 ^^ Da! nur noch einer.
0000020 0a 64 00 2e 2f 74 65 73 74 2e 74 61 72 00 0000036 ====
Hm. Jan? Hast du ne Idee? Is mein Tar zu alt?
==== $ tar --version | head -1 tar (GNU tar) 1.12 ====
Auf meiner nagelneuen SuSE 8.2 ists auch nur eine 1.13 und sie zeigt das gleiche Verhalten. Auf die Schnelle fällt mir jetzt nix ein - ich will ins Bett :-) Jan
Hallo, On Sat, 07 Jun 2003, Jan Trippler wrote:
On Fre, 06 Jun 2003 at 09:25 (+0200), David Haller wrote: [..]
dh@slarty[1]: /tmp/test3 (0)$ ls -b1 a\tb b\\tc c\nd [..] Wie's scheint hat aber find oder tar mit dem '\' Probleme:
==== $ find . -type f -print0 | tar cv -f test.tar --null -T - ./a\tb tar: Cannot add file ./b c: No such file or directory ./c\nd tar: Error exit delayed from previous errors ====
Man beachte aber: 'c\nd' wird mit eingepackt... Warum tar beim '\\t' net will versteh ich auch net. find macht jedenfalls das richtige:
IMHO stänkert die Shell da. Die Sonderbedeutung des Backslash als Entwerter wird ja nicht aufgehoben. Das sieht man auch daran, dass nur ein \ beim tar ankommt - das übliche Verhalten.
Nein, nicht die shell. Der Doppelbackslash ist ja die Sequenz fuer den einfachen Backslash, das erste '\' entwertet die Sonderfunktion des zweiten '\'.
$ find . -type f -print0 | od -tx1 0000000 2e 2f 61 09 62 00 2e 2f 62 5c 74 63 00 2e 2f 63 ^^ Da! nur noch einer.
Moment! Das ist ja auch richtig so! Die Datei heisst 'b backslash t c' und eben nicht 'a tab c'. Wie eben auch in der hex-Ausgabe zu sehen. D.h. tar expandiert faelschlich das backslash-t im Dateinamen zu einem tab...
Hm. Jan? Hast du ne Idee? Is mein Tar zu alt? [..] Auf meiner nagelneuen SuSE 8.2 ists auch nur eine 1.13 und sie zeigt das gleiche Verhalten. Auf die Schnelle fällt mir jetzt nix ein - ich will ins Bett :-)
*g* -dnh -- So etwas habe Ich mir schon gedacht. aber da das zuendeführen dieses Gedanken mir zu anstrengend war, habe Ich an dieser Stelle aufgehöhrt zu denken. [Woko° in dag°]
On Sam, 07 Jun 2003 at 17:57 (+0200), David Haller wrote:
On Sat, 07 Jun 2003, Jan Trippler wrote:
On Fre, 06 Jun 2003 at 09:25 (+0200), David Haller wrote: [..]
dh@slarty[1]: /tmp/test3 (0)$ ls -b1 a\tb b\\tc c\nd [...] $ find . -type f -print0 | od -tx1 0000000 2e 2f 61 09 62 00 2e 2f 62 5c 74 63 00 2e 2f 63 ^^ Da! nur noch einer.
Moment! Das ist ja auch richtig so! Die Datei heisst 'b backslash t c' und eben nicht 'a tab c'. Wie eben auch in der hex-Ausgabe zu sehen.
D.h. tar expandiert faelschlich das backslash-t im Dateinamen zu einem tab...
Ja. War wohl doch schon etwas spät ;-) Was der tar da macht, weiß ich nicht, aber folgender Trick funktioniert bei mir: jan@p4mobil:~/tmp/tartest> ls -b1 a\tb b\\tc c\nd jan@p4mobil:~/tmp/tartest> find . -type f -print0 | sed 's/\\/\\\\/g' | tar cvf ../test.tar --null -T - ./a\tb ./b\\tc ./c\nd jan@p4mobil:~/tmp/tartest> cd .. jan@p4mobil:~/tmp> mkdir tarx jan@p4mobil:~/tmp> cd tarx jan@p4mobil:~/tmp/tarx> tar xvf ../test.tar ./a\tb ./b\\tc ./c\nd jan@p4mobil:~/tmp/tarx> ls -b1 a\tb b\\tc c\nd Doof kann man sein, man muss sich nur zu helfen wissen ;-) Jan
Hallo, On Mon, 09 Jun 2003, Jan Trippler wrote:
On Sam, 07 Jun 2003 at 17:57 (+0200), David Haller wrote:
On Sat, 07 Jun 2003, Jan Trippler wrote:
On Fre, 06 Jun 2003 at 09:25 (+0200), David Haller wrote: [..]
dh@slarty[1]: /tmp/test3 (0)$ ls -b1 a\tb b\\tc c\nd [...] $ find . -type f -print0 | od -tx1 0000000 2e 2f 61 09 62 00 2e 2f 62 5c 74 63 00 2e 2f 63 ^^ Da! nur noch einer.
Moment! Das ist ja auch richtig so! Die Datei heisst 'b backslash t c' und eben nicht 'a tab c'. Wie eben auch in der hex-Ausgabe zu sehen.
D.h. tar expandiert faelschlich das backslash-t im Dateinamen zu einem tab...
Ja. War wohl doch schon etwas spät ;-)
Was der tar da macht, weiß ich nicht, aber folgender Trick funktioniert bei mir: [..] jan@p4mobil:~/tmp/tartest> find . -type f -print0 | sed 's/\\/\\\\/g' | tar cvf ../test.tar --null -T - ./a\tb ./b\\tc ./c\nd [..] Doof kann man sein, man muss sich nur zu helfen wissen ;-)
Darum geht's ja eigentlich ja auch nicht. Fuer die meisten (shell) Probleme finden sich ja "Wuergarounds" wie obiger, der die '\' einfach per sed verdoppelt. Im Sinne des Erfinders ist das jedenfalls nicht. IMO ist das ein Bug in tar... Wenn ich dran denke und Zeit habe, schau ich mir mal den code von 'tar' an und reiche ggfs. einen Bugreport ein... *MOMPL* ==== $ sash
-tar cvf test.tar * a a b a b\tc a c d tar tvf test.tar tar: Record size = 7 blocks -rw-r--r-- 500/1024 4 2003-06-06 09:06 a\tb -rw-r--r-- 500/1024 5 2003-06-06 09:07 b\\tc -rw-r--r-- 500/1024 4 2003-06-06 09:07 c\nd exit $ rm test.tar $ tar cvf test.tar * a\tb tar: Cannot add file b c: No such file or directory c\nd tar: Error exit delayed from previous errors $ rm test.tar ====
Da ist offenbar die mini tar-Implementation der sash besser als GNU-tar... Was meine Vermutung (-> Bug) bestaetigt... -dnh PS: $ tar --version | head -1 tar (GNU tar) 1.12 $ rpm -qf /bin/sash sash-3.4-41 $ rpm -q --queryformat "%{distribution}\n" -f /bin/sash /bin/tar SuSE Linux 6.4 (i386) SuSE Linux 6.2 (i386) Kann obiges mal jemand mit (anderen Versionen) nachvollziehen? PPS: Jan, ich denke, obiges Beispiel sollte mit in unser "kranke-Dateinamen"-Archiv... Ich fang die Tage mal einen tarball (sic!) an, weiteres per PM? Apropos: da faellt mir ein guter Dateiname fuer den tarball ein: "filename-insanity-check.tar" ;) Was ne Ironie, dass eben 'tar' da offenbar selber Schwierigkeiten hat... *lol* --
Alkohol ist Gift, und Gift gehoert Vernichtet Eben. Seh schon hier sin alle dem aloholizismus verfallen! Ach? Iss das ansteckend? *glugggluggglugg* *brööööööööhhhhhh* [aus suse-talk]
Hallo David, hallo Leute, Am Donnerstag, 12. Juni 2003 12:12 schrieb David Haller:
On Mon, 09 Jun 2003, Jan Trippler wrote:
On Sam, 07 Jun 2003 at 17:57 (+0200), David Haller wrote:
On Sat, 07 Jun 2003, Jan Trippler wrote:
On Fre, 06 Jun 2003 at 09:25 (+0200), David Haller wrote:
dh@slarty[1]: /tmp/test3 (0)$ ls -b1 a\tb b\\tc c\nd
Ich biete mal ein wenig mehr ;-) cb@tux:/tmp/tmp-cb/kranke_dateinamen> ls -1b a\tb b\\tc c\nd d\\ne x\\\\\\ty # Idee dazu kam nach dem folgenden: y\\\\tz # und diese Nettigkeit ist mir eher zufällig bei einem # "missglückten" touch entstanden ;-) [...]
D.h. tar expandiert faelschlich das backslash-t im Dateinamen zu einem tab...
Nicht nur \t, auch andere (z. B. ist es mir bei \n aufgefallen, mehr hab ich nicht getestet)
[...]IMO ist das ein Bug in tar... Wenn ich dran denke und Zeit habe, schau ich mir mal den code von 'tar' an und reiche ggfs. einen Bugreport ein...
Wäre wohl fällig, IMHO ;-) cb@tux:/tmp/tmp-cb/kranke_dateinamen> LANG=C tar cvf test.tar * a\tb tar: b\tc: Cannot stat: No such file or directory c\nd tar: d\ne: Cannot stat: No such file or directory tar: x\\\ty: Cannot stat: No such file or directory tar: y\\tz: Cannot stat: No such file or directory tar: Error exit delayed from previous errors Immerhin - zumindest in der Fehlermeldung stimmen die Dateiname wieder *g* (was allerdings IMHO ein Bug des Bugs ist ;-) [...]
PS: $ tar --version | head -1 tar (GNU tar) 1.12
cb@tux:/tmp/tmp-cb/kranke_dateinamen> tar --version |head -n1 tar (GNU tar) 1.13.25 SuSE 8.2
Kann obiges mal jemand mit (anderen Versionen) nachvollziehen?
Jepp, der Bug ist immer noch drin. Einziger Unterschied: in der Fehlermeldung werden die Dateinamen anscheinend richtig angezeigt (was ich nicht unbedingt gut finde, da so die Fehlersuche noch schwerer wird...) Und das tar der SuSE 8.2 sollte doch recht aktuell sein ;-)
PPS: Jan, ich denke, obiges Beispiel sollte mit in unser "kranke-Dateinamen"-Archiv... Ich fang die Tage mal einen tarball (sic!) an, weiteres per PM?
Nehmt Ihr mich auch in den Verteiler?
Apropos: da faellt mir ein guter Dateiname fuer den tarball ein: "filename-insanity-check.tar" ;) Was ne Ironie, dass eben 'tar' da offenbar selber Schwierigkeiten hat... *lol*
Naja, notfalls könnte man ja noch ein ZIP-Archiv erstellen *flücht* Scheint sogar zu funktionieren: cb@tux:/tmp/tmp-cb/kranke_dateinamen> zip test.zip * adding: a b (stored 0%) adding: b\tc (stored 0%) adding: c d (stored 0%) adding: d\ne (stored 0%) adding: x\\\ty (stored 0%) adding: y\\tz (stored 0%) Gruß Christian Boltz --
Yapp, wir hamm uns wieder lieb ;) Pinguine zeigen sich den Schnabel, dann geht dat wieder. Mönsch ist das Langweilig. *poppcornwiederwegräum* [> Thorsten von Plotho-Kettner und Bernd Brodesser in suse-linux]
Hallo, [nur ganz kurz, da schon im Halbschlaf...] On Fri, 13 Jun 2003, Christian Boltz wrote: [..]
Naja, notfalls könnte man ja noch ein ZIP-Archiv erstellen *flücht* Scheint sogar zu funktionieren: cb@tux:/tmp/tmp-cb/kranke_dateinamen> zip test.zip *
Nimm noch Dateien mit ':;\\b' in die Liste mit auf... -dnh -- ... I think the only way a true sysadmin can drag himself into work day after day is if he really believes, to the bottom of his black little heart, that It Can't Possibly Get Any Worse. ... you meant something rather different by "optimist"? -- J. D. Baldwin, in the Monastery
Hallo David, hallo Leute, Am Freitag, 13. Juni 2003 23:12 schrieb David Haller:
[nur ganz kurz, da schon im Halbschlaf...]
So früh? ;-)
On Fri, 13 Jun 2003, Christian Boltz wrote: [..]
Naja, notfalls könnte man ja noch ein ZIP-Archiv erstellen *flücht* Scheint sogar zu funktionieren: cb@tux:/tmp/tmp-cb/kranke_dateinamen> zip test.zip *
Nimm noch Dateien mit ':;\\b' in die Liste mit auf...
zip ist auf jeden Fall (bisher) verträglicher als tar ;-) Erste Stolperfalle war eine Datei mit \b (Backspace) im Namen, da wurde der Backspace einfach "verschluckt". Zur Info: cb@tux:/tmp/tmp-cb/kranke_dateinamen> zip -h| head -n3 | tail -n1 Zip 2.3 (November 29th 1999). Usage: Ach so, die IMHO kompatibelste Lösung zur Verteilung der kranken Dateinamen dürfte wohl ein kleines Script mit einer Reihe touch-Befehle sein ;-) Hätte übrigens auch den Vorteil, dass man das "touch" leicht z. B. durch ein "cp" oder "mkdir" o. ä. ersetzen kann, wenn ein Programm mehr als nur leere Dateien möchte ;-) Mein momentaner Stand: (Disclaimer für alle "Nicht-Experten": bitte nur ausprobieren, wenn Ihr auch wisst, wie man die erstellten Dateien wieder los wird ;-) touch '001 b' # tab touch '002\tc' touch '003 d' touch '004\ne' touch '005\\\ty' touch '006\\tz' touch '007:e' touch '008;f' touch '009\b' touch '010:;\\b' touch '011^Bg' # ^B = [Ctrl-v][Ctrl-b] touch '012*x' touch '013 $PATH' touch '014 "xy"' touch '015 "x' touch "016 'y" touch "017`echo -e \"abc\bdef\"`" touch '018a?b' # [1] touch '018a_b' # als "Ergänzung" zu 018a?b ;-) touch -- '--019-no-such-option' touch -- '-020' Die Nummerierung der Dateien halte ich übrigens für sinnvoll, damit man leichter auf den Dateinamen kommt, der beim Testen Probleme gemacht hat - wobei man über die Reihenfolge der Namen nochmal nachdenken sollte, da ja durch die Nummerierung eine "definierbare" Reihenfolge entsteht und wir IMHO eine Staffelung von "schafft fast jedes Programm" bis hin zu "wer das richtig handhabt, bekommt ein Extralob" ;-) haben sollten. Über die Verteiliung diverser Leerzeichen in den Dateinamen (insbesondere solcher, die irgendwie expandiert werden könnten, also alles mit *, ? oder $irgendwas) können wir noch diskutieren ;-) Gruß Christian Boltz [1] 018a?b wird übrigens von ls -b nicht korrekt gequoted ("?" statt "\?") und erwischt daher auch 018a_b :-( -> Bug in ls? [2] [2] Wenn wir lange genug über fiese Dateinamen nachdenken, fahren wir wohl jedes Programm an die Wand ;-) --
[Strings in C] Das würde alles nur Aussagen über die glibc erlauben. Aha, die ist Dir nicht autoritativ genug. Jetzt kenne ich endlich Dein eigentliches Problem: Der Papst muss die 0 am Ende absegnen ;-) [> Thorsten Haude und Jan Trippler in suse-linux]
Hallo, On Sun, 15 Jun 2003, Christian Boltz wrote:
Am Freitag, 13. Juni 2003 23:12 schrieb David Haller:
[nur ganz kurz, da schon im Halbschlaf...]
So früh? ;-)
Ja. Ich war seit 2:30 oder so wach...
On Fri, 13 Jun 2003, Christian Boltz wrote: [..]
Naja, notfalls könnte man ja noch ein ZIP-Archiv erstellen *flücht* Scheint sogar zu funktionieren: cb@tux:/tmp/tmp-cb/kranke_dateinamen> zip test.zip *
Nimm noch Dateien mit ':;\\b' in die Liste mit auf...
zip ist auf jeden Fall (bisher) verträglicher als tar ;-)
Hoi. Muss ich dann auch mal testen ;)
Erste Stolperfalle war eine Datei mit \b (Backspace) im Namen, da wurde der Backspace einfach "verschluckt". Zur Info:
Schluckt zip auch die mit den ':'? Die sind naemlich unter Win* und MacOS[3] illegal[4]...
cb@tux:/tmp/tmp-cb/kranke_dateinamen> zip -h| head -n3 | tail -n1 Zip 2.3 (November 29th 1999). Usage:
Hier: $ zip -h | headmidtail -s4:1 Zip 2.2 (November 3rd 1997). Usage: (bei mir war's noch ne Zeile mehr vor der Version ;) Erfreulich stabil das Teil offenbar, wenn zwischen 2.2 und 2.3 zwei Jahre liegen :)
Ach so, die IMHO kompatibelste Lösung zur Verteilung der kranken Dateinamen dürfte wohl ein kleines Script mit einer Reihe touch-Befehle sein ;-)
Ein sh-script wird fies bei den richtig fiesen Dateinamen... sollte aber fuer's meiste reichen... Evtl. geht awk, perl oder zur Not sogar C sollte auf jeden Fall gehen. Hm. Eigentlich sollten wir dann auch ein aufraeumen implementieren, denn die meisten Tools werden wohl an der ein oder anderen Datei scheitern (inkl. rm, mc u.a.)... Die Idee ist jedenfalls gut -- muss man mal testen... Andererseits: es interessiert ja nicht, wie wir das Archiv erstellen, solange tar das dann richtig auspackt... *eg* Haette den Vorteil, dass wir und nur mit den Bugs von tar naeher beschaeftigen muessten...
Hätte übrigens auch den Vorteil, dass man das "touch" leicht z. B. durch ein "cp" oder "mkdir" o. ä. ersetzen kann, wenn ein Programm mehr als nur leere Dateien möchte ;-) Mein momentaner Stand: (Disclaimer für alle "Nicht-Experten": bitte nur ausprobieren, wenn Ihr auch wisst, wie man die erstellten Dateien wieder los wird ;-)
Disclaimer muttu schreien! ;) WER DAS FOLGENDE AUSFUEHRT IST SELBER SCHULD!!!1
touch '001 b' # tab touch '002\tc' touch '003 d' touch '004\ne' touch '005\\\ty' touch '006\\tz'
Hier sollten wir wohl mind. bis zur 5 '\' Variante gehen... Backslashes werden wohl ein Hauptthema sein ;)
touch '007:e' touch '008;f' touch '009\b' touch '010:;\\b' touch '011^Bg' # ^B = [Ctrl-v][Ctrl-b]
Was ist daran (ASCII 0x02) interessant? Also im Vergleich z.B. zu '\a' oder '\f'? Oder hast du das mit '^H' (ASCII 0x08, '\b') verwelcshert? 'printf "^H...%10i"' (o.ae) verwende ich uebrigens im Statistikscript fuer die Fortschrittsanzeige ;)
touch '012*x' touch '013 $PATH' touch '014 "xy"' touch '015 "x' touch "016 'y" touch "017`echo -e \"abc\bdef\"`" touch '018a?b' # [1] touch '018a_b' # als "Ergänzung" zu 018a?b ;-) touch -- '--019-no-such-option' touch -- '-020'
*Schick* Jo, da is schon einiges versammelt ;) Es fehlt z.B. noch: touch '041`echo -e "\b"`' und diverse Varianten davon ;)) Im Prinzip muss man ja alles ausser '\0' und '/' abklopfen... Und von den Sonderzeichen noch mehr "escapte" Varianten...
Die Nummerierung der Dateien halte ich übrigens für sinnvoll, damit man leichter auf den Dateinamen kommt, der beim Testen Probleme gemacht hat - wobei man über die Reihenfolge der Namen nochmal nachdenken sollte, da ja durch die Nummerierung eine "definierbare" Reihenfolge entsteht und wir IMHO eine Staffelung von "schafft fast jedes Programm" bis hin zu "wer das richtig handhabt, bekommt ein Extralob" ;-) haben sollten.
Jup. Die Nummer wuerde ich aber nicht zu Beginn stellen, das entschaeft zu vieles (z.B. was waere mit '-\b; rm -rf'?)
Über die Verteiliung diverser Leerzeichen in den Dateinamen (insbesondere solcher, die irgendwie expandiert werden könnten, also alles mit *, ? oder $irgendwas) können wir noch diskutieren ;-)
*g*
[1] 018a?b wird übrigens von ls -b nicht korrekt gequoted ("?" statt "\?") und erwischt daher auch 018a_b :-( -> Bug in ls? [2]
Hm. Bei mir wird das als \? angezeigt (ich hab aber noch nicht alle anderen, die touch evtl. trotz der '' expandieren koennte). Bash 2.03, ls (fileutils) 4.0...
[2] Wenn wir lange genug über fiese Dateinamen nachdenken, fahren wir wohl jedes Programm an die Wand ;-)
Jau. Naja, die meisten zumindest *eg* -dnh [3] da dort Pfadtrenner analog '/' [4] wie das unter MacOS X genau aussieht weiss ich nicht, wg. dem BSD-Unix drunter sind sicher auch noch die '/' "illegal"... -- Das ist keine Sigg, Zum Kuckuck noch mal! Und wenn du eine daraus machst, so ist das deine Schuld. [WoKo zu Michael Hoffmann in dag°]
Hallo David, hallo Leute, Am Sonntag, 15. Juni 2003 01:58 schrieb David Haller:
On Sun, 15 Jun 2003, Christian Boltz wrote:
Am Freitag, 13. Juni 2003 23:12 schrieb David Haller:
On Fri, 13 Jun 2003, Christian Boltz wrote: [..]
Naja, notfalls könnte man ja noch ein ZIP-Archiv erstellen *flücht* Scheint sogar zu funktionieren: cb@tux:/tmp/tmp-cb/kranke_dateinamen> zip test.zip *
Nimm noch Dateien mit ':;\\b' in die Liste mit auf...
zip ist auf jeden Fall (bisher) verträglicher als tar ;-)
Hoi. Muss ich dann auch mal testen ;)
Erste Stolperfalle war eine Datei mit \b (Backspace) im Namen, da wurde der Backspace einfach "verschluckt". Zur Info:
Schluckt zip auch die mit den ':'? Die sind naemlich unter Win* und MacOS[3] illegal[4]...
Nö, die bleiben erhalten. Aber ich hab gerade gesehen, dass zip doch nicht so ideal ist, da es noch einige andere Zeichen (Tab, Zeilenumbruch) schluckt :-(
Ach so, die IMHO kompatibelste Lösung zur Verteilung der kranken Dateinamen dürfte wohl ein kleines Script mit einer Reihe touch-Befehle sein ;-)
Ein sh-script wird fies bei den richtig fiesen Dateinamen... sollte
-v bitte. Was verstehst Du unter "richtig fies"? (Beispiele?)
aber fuer's meiste reichen... Evtl. geht awk, perl oder zur Not sogar C sollte auf jeden Fall gehen. Hm.
Sicher, dass wir solche "Kanonen" wirklich brauchen, nur um leere Dateien anzulegen? Die Variante Shellscript hätte übrigens noch den Vorteil, dass wir es auch allgemeiner schreiben können: CMD=touch $CMD 'a"b' $CMD '[...]' Apropos: [irgendwas] wäre auch eine nette Idee ;-) Backticks fehlen uns auch noch...
Eigentlich sollten wir dann auch ein aufraeumen implementieren, denn die meisten Tools werden wohl an der ein oder anderen Datei scheitern (inkl. rm, mc u.a.)...
*g*
Die Idee ist jedenfalls gut -- muss man mal testen... Andererseits: es interessiert ja nicht, wie wir das Archiv erstellen, solange tar das dann richtig auspackt... *eg* Haette den Vorteil, dass wir und nur mit den Bugs von tar naeher beschaeftigen muessten...
Als Shellscript hätten wir auch die tar-Bugs los ;-) Außerdem bringt diese Variante weitere Vorteile: - Lerneffekt ("wie muss man den Dateinamen quoten?") - leichtere Austauschbarkeit (z. B. per Mail, es ginge theoretisch sogar per CVS ;-)
Hätte übrigens auch den Vorteil, dass man das "touch" leicht z. B. durch ein "cp" oder "mkdir" o. ä. ersetzen kann, wenn ein Programm mehr als nur leere Dateien möchte ;-) Mein momentaner Stand: (Disclaimer für alle "Nicht-Experten": bitte nur ausprobieren, wenn Ihr auch wisst, wie man die erstellten Dateien wieder los wird ;-)
Disclaimer muttu schreien! ;)
Stimmt auch wieder ;-)
WER DAS FOLGENDE AUSFUEHRT IST SELBER SCHULD!!!1
Jepp.
touch '001 b' # tab touch '002\tc' touch '003 d' touch '004\ne' touch '005\\\ty' touch '006\\tz'
Hier sollten wir wohl mind. bis zur 5 '\' Variante gehen... Backslashes werden wohl ein Hauptthema sein ;)
Stimmt wohl
touch '007:e' touch '008;f' touch '009\b' touch '010:;\\b' touch '011^Bg' # ^B = [Ctrl-v][Ctrl-b]
Was ist daran (ASCII 0x02) interessant?
Naja, es ist ein Sonderzeichen, sonst fällt mir auch kein Grund ein ;-) Ich würde es sowieso als sinnvoll betrachten, alle (auch "uninteressante") Sonderzeichen dabeizuhaben. Also quasi alles von ASCII 1 bis 255 mit Ausnahme des / ;-)
Also im Vergleich z.B. zu '\a' oder '\f'? Oder hast du das mit '^H' (ASCII 0x08, '\b') verwelcshert?
'printf "^H...%10i"' (o.ae) verwende ich uebrigens im Statistikscript fuer die Fortschrittsanzeige ;)
Sollten wir dann wohl auch noch aufnehmen ;-)
touch '012*x' touch '013 $PATH' touch '014 "xy"' touch '015 "x' touch "016 'y" touch "017`echo -e \"abc\bdef\"`" touch '018a?b' # [1] touch '018a_b' # als "Ergänzung" zu 018a?b ;-) touch -- '--019-no-such-option' touch -- '-020'
*Schick* Jo, da is schon einiges versammelt ;) Es fehlt z.B. noch:
touch '041`echo -e "\b"`'
Auch nett ;-)
und diverse Varianten davon ;)) Im Prinzip muss man ja alles ausser '\0' und '/' abklopfen...
Eben.
Und von den Sonderzeichen noch mehr "escapte" Varianten...
Klar.
Die Nummerierung der Dateien halte ich übrigens für sinnvoll, damit man leichter auf den Dateinamen kommt, der beim Testen Probleme gemacht hat - wobei man über die Reihenfolge der Namen nochmal nachdenken sollte, da ja durch die Nummerierung eine "definierbare" Reihenfolge entsteht und wir IMHO eine Staffelung von "schafft fast jedes Programm" bis hin zu "wer das richtig handhabt, bekommt ein Extralob" ;-) haben sollten.
Jup. Die Nummer wuerde ich aber nicht zu Beginn stellen, das entschaeft zu vieles (z.B. was waere mit '-\b; rm -rf'?)
Die können auch gern ans Ende wandern (evtl. nur wenn nötig -> definierbare Reihenfolge)
Über die Verteiliung diverser Leerzeichen in den Dateinamen (insbesondere solcher, die irgendwie expandiert werden könnten, also alles mit *, ? oder $irgendwas) können wir noch diskutieren ;-)
*g*
[1] 018a?b wird übrigens von ls -b nicht korrekt gequoted ("?" statt "\?") und erwischt daher auch 018a_b :-( -> Bug in ls? [2]
Hm. Bei mir wird das als \? angezeigt (ich hab aber noch nicht alle anderen, die touch evtl. trotz der '' expandieren koennte). Bash 2.03, ls (fileutils) 4.0...
rpm -qf /bin/ls /bin/bash coreutils-4.5.8-11 bash-2.05b-105 Vielleicht wurde da ja das Vorgehen von ls geändert. Ich sehe gerade, dass auch einige andere Zeichen nicht gequoted werden, z. B. [] Wobei ich gerade ein wenig in info ls gestöbert habe und u. a. auf die Option --quoting-style=... (bzw. $QUOTING_STYLE) gestoßen bin. Da gibt es die Möglichkeit, nach diversen Varianten zu quoten - siehe info ls (notfalls irgendwo[TM] online, falls Dein ls zu alt ist ;-)
[2] Wenn wir lange genug über fiese Dateinamen nachdenken, fahren wir wohl jedes Programm an die Wand ;-)
Jau. Naja, die meisten zumindest *eg*
Mal sehen, was alles unsere fiesen Dateinamen "überlebt" ;-) Gruß Christian Boltz PS: von mir aus können wir (wie von Jan vorgeschlagen) gern per PM weitermachen. -- If Microsoft is the solution, I want my problems back.
* Axel Heinrici schrieb am 05.Jun.2003:
Ich durchforste gerade die Doku zu find und tar und stehe vor einem Problem. Ich suche eine Möglichkeit tar beizubringen eine Dateiliste von stdin zu lesen. Etwa so: echo "filename1 filename2" | tar -cf archiv.tar --unbekannteOption So dass dann beide Dateien in dem Archiv sind. Oder kann tar nur mittels -T die Filenamen aus einem anderen File lesen? Das finde ich irgendwie unpraktisch.
Verwende doch xargs: echo "filename1 filename2" | xargs tar -cf archiv.tar nur falls es n filename1 usw. kein Leerzeichen gibt. Siehe man xargs. Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
* Axel Heinrici schrieb am 05.Jun.2003:
Ich durchforste gerade die Doku zu find und tar und stehe vor einem Problem. Ich suche eine Möglichkeit tar beizubringen eine Dateiliste von stdin zu lesen. Etwa so: echo "filename1 filename2" | tar -cf archiv.tar --unbekannteOption So dass dann beide Dateien in dem Archiv sind. Oder kann tar nur mittels -T die Filenamen aus einem anderen File lesen? Das finde ich irgendwie unpraktisch.
B.Brodesser@t-online.de (Bernd Brodesser)
Verwende doch xargs:
echo "filename1 filename2" | xargs tar -cf archiv.tar
nur falls es n filename1 usw. kein Leerzeichen gibt.
Siehe man xargs.
Aber Achtung, wenn es zuviele Namen sind, dann ruft xargs das Programm mehrfach auf, und ob das das gewünschte ist???? Besser: man tar: -T, --files-from=F get names to extract or create from file F Jürgen -- Dr.rer.nat. Juergen Vollmer, Viktoriastrasse 15, D-76133 Karlsruhe Tel: +49(721) 9204871 Fax: +49(721) 24874 juergen.vollmer@[informatik-vollmer.de|alumni.uni-karlsruhe.de|acm.org] www.informatik-vollmer.de
participants (7)
-
Axel Heinrici -
B.Brodesser＠t-online.de -
Christian Boltz -
David Haller -
Jan.Trippler＠t-online.de -
Jürgen Vollmer -
Peter Wiersig