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.